<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow-IPC: util/sync_io/sync_io_fwd.hpp Source File</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow-IPC<span id="projectnumber">&#160;1.0.2</span>
   </div>
   <div id="projectbrief">Flow-IPC project: Full implementation reference.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div id="nav-path" class="navpath">
  <ul>
<li class="navelem"><a class="el" href="dir_a762a7cb84c76c9561dbc78c61068184.html">util</a></li><li class="navelem"><a class="el" href="dir_ff5224d8270264443126f24ce9d073a6.html">sync_io</a></li>  </ul>
</div>
</div><!-- top -->
<div class="header">
  <div class="headertitle"><div class="title">sync_io_fwd.hpp</div></div>
</div><!--header-->
<div class="contents">
<a href="sync__io__fwd_8hpp.html">Go to the documentation of this file.</a><div class="fragment"><div class="line"><a id="l00001" name="l00001"></a><span class="lineno">    1</span><span class="comment">/* Flow-IPC: Core</span></div>
<div class="line"><a id="l00002" name="l00002"></a><span class="lineno">    2</span><span class="comment"> * Copyright 2023 Akamai Technologies, Inc.</span></div>
<div class="line"><a id="l00003" name="l00003"></a><span class="lineno">    3</span><span class="comment"> *</span></div>
<div class="line"><a id="l00004" name="l00004"></a><span class="lineno">    4</span><span class="comment"> * Licensed under the Apache License, Version 2.0 (the</span></div>
<div class="line"><a id="l00005" name="l00005"></a><span class="lineno">    5</span><span class="comment"> * &quot;License&quot;); you may not use this file except in</span></div>
<div class="line"><a id="l00006" name="l00006"></a><span class="lineno">    6</span><span class="comment"> * compliance with the License.  You may obtain a copy</span></div>
<div class="line"><a id="l00007" name="l00007"></a><span class="lineno">    7</span><span class="comment"> * of the License at</span></div>
<div class="line"><a id="l00008" name="l00008"></a><span class="lineno">    8</span><span class="comment"> *</span></div>
<div class="line"><a id="l00009" name="l00009"></a><span class="lineno">    9</span><span class="comment"> *   https://www.apache.org/licenses/LICENSE-2.0</span></div>
<div class="line"><a id="l00010" name="l00010"></a><span class="lineno">   10</span><span class="comment"> *</span></div>
<div class="line"><a id="l00011" name="l00011"></a><span class="lineno">   11</span><span class="comment"> * Unless required by applicable law or agreed to in</span></div>
<div class="line"><a id="l00012" name="l00012"></a><span class="lineno">   12</span><span class="comment"> * writing, software distributed under the License is</span></div>
<div class="line"><a id="l00013" name="l00013"></a><span class="lineno">   13</span><span class="comment"> * distributed on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR</span></div>
<div class="line"><a id="l00014" name="l00014"></a><span class="lineno">   14</span><span class="comment"> * CONDITIONS OF ANY KIND, either express or implied.</span></div>
<div class="line"><a id="l00015" name="l00015"></a><span class="lineno">   15</span><span class="comment"> * See the License for the specific language governing</span></div>
<div class="line"><a id="l00016" name="l00016"></a><span class="lineno">   16</span><span class="comment"> * permissions and limitations under the License. */</span></div>
<div class="line"><a id="l00017" name="l00017"></a><span class="lineno">   17</span><span class="comment"></span> </div>
<div class="line"><a id="l00018" name="l00018"></a><span class="lineno">   18</span><span class="comment">/// @file</span></div>
<div class="line"><a id="l00019" name="l00019"></a><span class="lineno">   19</span><span class="comment"></span><span class="preprocessor">#pragma once</span></div>
<div class="line"><a id="l00020" name="l00020"></a><span class="lineno">   20</span> </div>
<div class="line"><a id="l00021" name="l00021"></a><span class="lineno">   21</span><span class="preprocessor">#include &quot;<a class="code" href="util__fwd_8hpp.html">ipc/util/util_fwd.hpp</a>&quot;</span></div>
<div class="line"><a id="l00022" name="l00022"></a><span class="lineno">   22</span><span class="preprocessor">#include &lt;boost/shared_ptr.hpp&gt;</span></div>
<div class="line"><a id="l00023" name="l00023"></a><span class="lineno">   23</span><span class="comment"></span> </div>
<div class="line"><a id="l00024" name="l00024"></a><span class="lineno">   24</span><span class="comment">/**</span></div>
<div class="line"><a id="l00025" name="l00025"></a><span class="lineno">   25</span><span class="comment"> * Contains common code, as well as important explanatory documentation in the following text, for the `sync_io`</span></div>
<div class="line"><a id="l00026" name="l00026"></a><span class="lineno">   26</span><span class="comment"> * pattern used in ipc::transport and ipc::session to provide fine-tuned control over integrating</span></div>
<div class="line"><a id="l00027" name="l00027"></a><span class="lineno">   27</span><span class="comment"> * asynchronous Flow-IPC activities into the user&#39;s event loop.</span></div>
<div class="line"><a id="l00028" name="l00028"></a><span class="lineno">   28</span><span class="comment"> *</span></div>
<div class="line"><a id="l00029" name="l00029"></a><span class="lineno">   29</span><span class="comment"> * ### What&#39;s all this, then? ###</span></div>
<div class="line"><a id="l00030" name="l00030"></a><span class="lineno">   30</span><span class="comment"> * You may notice that for ~every class/class template `X` in this library that provides 1+ `X::async_*(..., F)`</span></div>
<div class="line"><a id="l00031" name="l00031"></a><span class="lineno">   31</span><span class="comment"> * method(s), where `F()` is a completion handler for an async operation, there exists also -- in a sub-namespace</span></div>
<div class="line"><a id="l00032" name="l00032"></a><span class="lineno">   32</span><span class="comment"> * named `sync_io` -- a similar-looking type `sync_io::X`.</span></div>
<div class="line"><a id="l00033" name="l00033"></a><span class="lineno">   33</span><span class="comment"> *</span></div>
<div class="line"><a id="l00034" name="l00034"></a><span class="lineno">   34</span><span class="comment"> * @note At times, generally in ipc::session and class template ipc::transport::struc::Channel specifically, async</span></div>
<div class="line"><a id="l00035" name="l00035"></a><span class="lineno">   35</span><span class="comment"> *       ops don&#39;t necessarily use `async_*` naming, but the point remains that: an operation occurs in some</span></div>
<div class="line"><a id="l00036" name="l00036"></a><span class="lineno">   36</span><span class="comment"> *       sense in the background, and then a *handler* function, given as an arg, is called when the operation is</span></div>
<div class="line"><a id="l00037" name="l00037"></a><span class="lineno">   37</span><span class="comment"> *       completed.  Neverthelss for this discussion we will often take the case of, indeed, an operation</span></div>
<div class="line"><a id="l00038" name="l00038"></a><span class="lineno">   38</span><span class="comment"> *       named `X::async_*(..., F)`, with `F()` a one-off completion handler.  It&#39;s the basic, most mainstream pattern.</span></div>
<div class="line"><a id="l00039" name="l00039"></a><span class="lineno">   39</span><span class="comment"> *</span></div>
<div class="line"><a id="l00040" name="l00040"></a><span class="lineno">   40</span><span class="comment"> * Long story short, all else being equal, we would recommend the use of `X`</span></div>
<div class="line"><a id="l00041" name="l00041"></a><span class="lineno">   41</span><span class="comment"> * over `sync_io::X`: it is easier (in most cases), less error-prone, and delivers</span></div>
<div class="line"><a id="l00042" name="l00042"></a><span class="lineno">   42</span><span class="comment"> * similar performance -- quite possibly even better (due to automatic parallelization albeit at the cost</span></div>
<div class="line"><a id="l00043" name="l00043"></a><span class="lineno">   43</span><span class="comment"> * of mandatory context-switching).  However `sync_io::X` does exist for a good reason, at least for some important</span></div>
<div class="line"><a id="l00044" name="l00044"></a><span class="lineno">   44</span><span class="comment"> * `X`es, and in an advanced, highly peformance-sensitive application it may be worth considering switching</span></div>
<div class="line"><a id="l00045" name="l00045"></a><span class="lineno">   45</span><span class="comment"> * to the *direct* use of `sync_io::X`.  For what it is worth, internally `X` is usually written</span></div>
<div class="line"><a id="l00046" name="l00046"></a><span class="lineno">   46</span><span class="comment"> * in terms of `sync_io::X`; the latter is essentially the core logic, while the former provides</span></div>
<div class="line"><a id="l00047" name="l00047"></a><span class="lineno">   47</span><span class="comment"> * auto-parallelization and a simpler interface.</span></div>
<div class="line"><a id="l00048" name="l00048"></a><span class="lineno">   48</span><span class="comment"> *</span></div>
<div class="line"><a id="l00049" name="l00049"></a><span class="lineno">   49</span><span class="comment"> * @note For this reason comments sometimes refer to a `sync_io::X` *core*: where the basic `X`-ish capabalities and</span></div>
<div class="line"><a id="l00050" name="l00050"></a><span class="lineno">   50</span><span class="comment"> *       data live.  The *async-I/O* `X` is then often built around a `sync_io::X` core.  Because of this it is</span></div>
<div class="line"><a id="l00051" name="l00051"></a><span class="lineno">   51</span><span class="comment"> *       usually easy, and fast, to convert a `sync_io::X` into an `X` -- via a move-like ctor called</span></div>
<div class="line"><a id="l00052" name="l00052"></a><span class="lineno">   52</span><span class="comment"> *       `sync_io`-core *adopting ctor*.  Additionally, ipc::transport::Channel template -- which bundles local peer</span></div>
<div class="line"><a id="l00053" name="l00053"></a><span class="lineno">   53</span><span class="comment"> *       objects of 1-2 IPC pipes -- can bundle *either* async-I/O peer objects *or* `sync_io` peer objects, and</span></div>
<div class="line"><a id="l00054" name="l00054"></a><span class="lineno">   54</span><span class="comment"> *       one can always convert the latter to the former by calling `x.async_io_obj()`.</span></div>
<div class="line"><a id="l00055" name="l00055"></a><span class="lineno">   55</span><span class="comment"> *</span></div>
<div class="line"><a id="l00056" name="l00056"></a><span class="lineno">   56</span><span class="comment"> * @note In cases where performance is not a real concern, such as for the assumed-rare</span></div>
<div class="line"><a id="l00057" name="l00057"></a><span class="lineno">   57</span><span class="comment"> *       ipc::session::Session_server::async_accept() operations, internally `sync_io::X` may actually be written</span></div>
<div class="line"><a id="l00058" name="l00058"></a><span class="lineno">   58</span><span class="comment"> *       in terms of `X` instead... but we digress.  Either way it is a black box.</span></div>
<div class="line"><a id="l00059" name="l00059"></a><span class="lineno">   59</span><span class="comment"> *</span></div>
<div class="line"><a id="l00060" name="l00060"></a><span class="lineno">   60</span><span class="comment"> * Some examples of `X`es that have `sync_io::X` counterparts:</span></div>
<div class="line"><a id="l00061" name="l00061"></a><span class="lineno">   61</span><span class="comment"> *   - core-layer transport::Native_socket_stream</span></div>
<div class="line"><a id="l00062" name="l00062"></a><span class="lineno">   62</span><span class="comment"> *     (including its `async_receive_*()`, and the handler-less -- but nevertheless potentially</span></div>
<div class="line"><a id="l00063" name="l00063"></a><span class="lineno">   63</span><span class="comment"> *     asynchronous -- `send_*()`) and all other `Blob_sender`, `Blob_receiver`, `Native_handle_sender`,</span></div>
<div class="line"><a id="l00064" name="l00064"></a><span class="lineno">   64</span><span class="comment"> *     `Native_handle_receiver` concept impls including the bundling transport::Channel;</span></div>
<div class="line"><a id="l00065" name="l00065"></a><span class="lineno">   65</span><span class="comment"> *   - structured-layer ipc::transport::struc::Channel;</span></div>
<div class="line"><a id="l00066" name="l00066"></a><span class="lineno">   66</span><span class="comment"> *   - session::Client_session (with its channel-accept and error handlers) and session::Session_server (ditto, plus</span></div>
<div class="line"><a id="l00067" name="l00067"></a><span class="lineno">   67</span><span class="comment"> *     with its `async_accept()`);</span></div>
<div class="line"><a id="l00068" name="l00068"></a><span class="lineno">   68</span><span class="comment"> *     - all their session::shm counterparts.</span></div>
<div class="line"><a id="l00069" name="l00069"></a><span class="lineno">   69</span><span class="comment"> *</span></div>
<div class="line"><a id="l00070" name="l00070"></a><span class="lineno">   70</span><span class="comment"> * ### The async-I/O (default) pattern ###</span></div>
<div class="line"><a id="l00071" name="l00071"></a><span class="lineno">   71</span><span class="comment"> * Consider `X` -- take for example transport::Native_socket_stream -- and a particular async operation -- take,</span></div>
<div class="line"><a id="l00072" name="l00072"></a><span class="lineno">   72</span><span class="comment"> * e.g., transport::Native_socket_stream::async_receive_blob().</span></div>
<div class="line"><a id="l00073" name="l00073"></a><span class="lineno">   73</span><span class="comment"> *</span></div>
<div class="line"><a id="l00074" name="l00074"></a><span class="lineno">   74</span><span class="comment"> * When `x.async_receive_blob(..., F)` is invoked, `F()` is the user-specified completion handler, while ...</span></div>
<div class="line"><a id="l00075" name="l00075"></a><span class="lineno">   75</span><span class="comment"> * specifies details about the operation, in this case the target buffer where to write data.  It works as follows:</span></div>
<div class="line"><a id="l00076" name="l00076"></a><span class="lineno">   76</span><span class="comment"> * `x` attempts to perform the operation (in this case receive a single in-message as soon as it becomes available</span></div>
<div class="line"><a id="l00077" name="l00077"></a><span class="lineno">   77</span><span class="comment"> * which may or may not be instant); and once it has suceeded, it invokes `F(...)` (where ... indicates</span></div>
<div class="line"><a id="l00078" name="l00078"></a><span class="lineno">   78</span><span class="comment"> * results, usually at least an `Error_code`) from *an unspecified thread* that is not the user&#39;s calling thread</span></div>
<div class="line"><a id="l00079" name="l00079"></a><span class="lineno">   79</span><span class="comment"> * (call it thread U, where `x.async_*()` was called).  Even if the op completes immediately, `x.async_*()` will</span></div>
<div class="line"><a id="l00080" name="l00080"></a><span class="lineno">   80</span><span class="comment"> * never invoke `F()` synchronously; always from the *unspecified thread*.</span></div>
<div class="line"><a id="l00081" name="l00081"></a><span class="lineno">   81</span><span class="comment"> *</span></div>
<div class="line"><a id="l00082" name="l00082"></a><span class="lineno">   82</span><span class="comment"> * That&#39;s great, but what does really happen?  Answer: `x`, usually at construction, invisibly, starts a separate</span></div>
<div class="line"><a id="l00083" name="l00083"></a><span class="lineno">   83</span><span class="comment"> * thread (technically it could be co-using a thread with other objects; but in reality as of this writing each</span></div>
<div class="line"><a id="l00084" name="l00084"></a><span class="lineno">   84</span><span class="comment"> * object really starts a thread).  An async operation might complete synchronously (perhaps a message is available</span></div>
<div class="line"><a id="l00085" name="l00085"></a><span class="lineno">   85</span><span class="comment"> * in a kernel receive buffer and is therefore immediately, internally, received inside `x.async_receive_blob()`</span></div>
<div class="line"><a id="l00086" name="l00086"></a><span class="lineno">   86</span><span class="comment"> * body); or it might occur in the background and involve (internally) async waiting of native-handle readability --</span></div>
<div class="line"><a id="l00087" name="l00087"></a><span class="lineno">   87</span><span class="comment"> * possibly even more threads might start (internally) to get things to work.  *Either* way, there is that thread --</span></div>
<div class="line"><a id="l00088" name="l00088"></a><span class="lineno">   88</span><span class="comment"> * call it thread W -- where *at least* the completion handler `F()` will be called.</span></div>
<div class="line"><a id="l00089" name="l00089"></a><span class="lineno">   89</span><span class="comment"> *</span></div>
<div class="line"><a id="l00090" name="l00090"></a><span class="lineno">   90</span><span class="comment"> * (If `x` is destroyed before this has a chance to happen, the `x`</span></div>
<div class="line"><a id="l00091" name="l00091"></a><span class="lineno">   91</span><span class="comment"> * destructor shall -- last-thing -- invoke `F()`, passing it the special</span></div>
<div class="line"><a id="l00092" name="l00092"></a><span class="lineno">   92</span><span class="comment"> * operation-aborted `Error_code`.  That is the case for one-off async-ops like that one.  There are also variations</span></div>
<div class="line"><a id="l00093" name="l00093"></a><span class="lineno">   93</span><span class="comment"> * such as the completion handlers of transport::struc::Channel, but the key point -- that work happens in</span></div>
<div class="line"><a id="l00094" name="l00094"></a><span class="lineno">   94</span><span class="comment"> * the background, in the object-created own thread W, and user-supplied handlers are run from thread W -- remains</span></div>
<div class="line"><a id="l00095" name="l00095"></a><span class="lineno">   95</span><span class="comment"> * the same.  Another variation is async-ops that don&#39;t require a completion handler; for example</span></div>
<div class="line"><a id="l00096" name="l00096"></a><span class="lineno">   96</span><span class="comment"> * transport::Native_socket_stream::send_blob() may perform work in the background upon encountering would-block</span></div>
<div class="line"><a id="l00097" name="l00097"></a><span class="lineno">   97</span><span class="comment"> * conditions internally -- and this again occurs in thread W -- but there is no completion handler to invoke.)</span></div>
<div class="line"><a id="l00098" name="l00098"></a><span class="lineno">   98</span><span class="comment"> *</span></div>
<div class="line"><a id="l00099" name="l00099"></a><span class="lineno">   99</span><span class="comment"> * What is the user supposed to do with an async-op like this?  In practice we tend to think of this in terms</span></div>
<div class="line"><a id="l00100" name="l00100"></a><span class="lineno">  100</span><span class="comment"> * of 2 basic possiblities for how the user&#39;s own event loop might be organized.</span></div>
<div class="line"><a id="l00101" name="l00101"></a><span class="lineno">  101</span><span class="comment"> *   - Proactor pattern: This is what boost.asio uses, what flow.async facilitates further, and what we generally</span></div>
<div class="line"><a id="l00102" name="l00102"></a><span class="lineno">  102</span><span class="comment"> *     recommend all else being equal.  We won&#39;t describe it here in detail, but integrating such a loop with</span></div>
<div class="line"><a id="l00103" name="l00103"></a><span class="lineno">  103</span><span class="comment"> *     this async-I/O pattern in Flow-IPC is quite simple:</span></div>
<div class="line"><a id="l00104" name="l00104"></a><span class="lineno">  104</span><span class="comment"> *     -# Call `x.async_*(..., F)` as explained above.</span></div>
<div class="line"><a id="l00105" name="l00105"></a><span class="lineno">  105</span><span class="comment"> *     -# As `F()` supply a short wrapper that will place the true handling of the event onto the same event loop --</span></div>
<div class="line"><a id="l00106" name="l00106"></a><span class="lineno">  106</span><span class="comment"> *        thread U (though multiple such threads might be in use alternatively) -- where you invoked `x.async_*(F)`.</span></div>
<div class="line"><a id="l00107" name="l00107"></a><span class="lineno">  107</span><span class="comment"> *        For example:</span></div>
<div class="line"><a id="l00108" name="l00108"></a><span class="lineno">  108</span><span class="comment"> *</span></div>
<div class="line"><a id="l00109" name="l00109"></a><span class="lineno">  109</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00110" name="l00110"></a><span class="lineno">  110</span><span class="comment"> *     ...</span></div>
<div class="line"><a id="l00111" name="l00111"></a><span class="lineno">  111</span><span class="comment"> *     m_my_asio_loop.post([t]() { start_async_op(); }</span></div>
<div class="line"><a id="l00112" name="l00112"></a><span class="lineno">  112</span><span class="comment"> *     ...</span></div>
<div class="line"><a id="l00113" name="l00113"></a><span class="lineno">  113</span><span class="comment"> *   void start_async_op()</span></div>
<div class="line"><a id="l00114" name="l00114"></a><span class="lineno">  114</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00115" name="l00115"></a><span class="lineno">  115</span><span class="comment"> *     // We are in thread U.</span></div>
<div class="line"><a id="l00116" name="l00116"></a><span class="lineno">  116</span><span class="comment"> *     x.async_receive_blob(..., [this](const Error_code&amp; err_code, size_t sz)</span></div>
<div class="line"><a id="l00117" name="l00117"></a><span class="lineno">  117</span><span class="comment"> *     {</span></div>
<div class="line"><a id="l00118" name="l00118"></a><span class="lineno">  118</span><span class="comment"> *       // We are in &quot;unspecified thread&quot; W.</span></div>
<div class="line"><a id="l00119" name="l00119"></a><span class="lineno">  119</span><span class="comment"> *       m_my_asio_loop.post([this, err_code, sz]() { on_async_op_done(err_code, sz); }</span></div>
<div class="line"><a id="l00120" name="l00120"></a><span class="lineno">  120</span><span class="comment"> *     }</span></div>
<div class="line"><a id="l00121" name="l00121"></a><span class="lineno">  121</span><span class="comment"> *   }</span></div>
<div class="line"><a id="l00122" name="l00122"></a><span class="lineno">  122</span><span class="comment"> *   void on_async_op_done(const Error_code&amp; err_code, size_t sz)</span></div>
<div class="line"><a id="l00123" name="l00123"></a><span class="lineno">  123</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00124" name="l00124"></a><span class="lineno">  124</span><span class="comment"> *     // We are in thread U.</span></div>
<div class="line"><a id="l00125" name="l00125"></a><span class="lineno">  125</span><span class="comment"> *     // ...handle it....</span></div>
<div class="line"><a id="l00126" name="l00126"></a><span class="lineno">  126</span><span class="comment"> *   }</span></div>
<div class="line"><a id="l00127" name="l00127"></a><span class="lineno">  127</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00128" name="l00128"></a><span class="lineno">  128</span><span class="comment"> *</span></div>
<div class="line"><a id="l00129" name="l00129"></a><span class="lineno">  129</span><span class="comment"> * Alternatively:</span></div>
<div class="line"><a id="l00130" name="l00130"></a><span class="lineno">  130</span><span class="comment"> *   - Reactor pattern: Usually built on top of an OS-supplied blocking polling method of some kind -- in POSIX</span></div>
<div class="line"><a id="l00131" name="l00131"></a><span class="lineno">  131</span><span class="comment"> *     nowadays usually at least `poll()`, in Linux possibly using the more advanced `epoll_*()` -- which centers</span></div>
<div class="line"><a id="l00132" name="l00132"></a><span class="lineno">  132</span><span class="comment"> *     on an &quot;FD-set&quot; (native handle set), where one describes `Native_handle`s (FDs) and the events one awaits</span></div>
<div class="line"><a id="l00133" name="l00133"></a><span class="lineno">  133</span><span class="comment"> *     (readable, writable) for each; and in each event loop iteration one runs a poll-wait operation</span></div>
<div class="line"><a id="l00134" name="l00134"></a><span class="lineno">  134</span><span class="comment"> *     (like `poll()` or `epoll_wait()`).  This blocks until 1 or more events-of-interest are active; then wakes up</span></div>
<div class="line"><a id="l00135" name="l00135"></a><span class="lineno">  135</span><span class="comment"> *     and reports which ones they were.  User code then synchronously invokes handling for each event of interest;</span></div>
<div class="line"><a id="l00136" name="l00136"></a><span class="lineno">  136</span><span class="comment"> *     such handling might modify the events-of-interest set, etc., until all such work is done, and the</span></div>
<div class="line"><a id="l00137" name="l00137"></a><span class="lineno">  137</span><span class="comment"> *     next poll-wait op executes.  Thus in the reactor pattern methods like `on_async_op_done()` are invoked</span></div>
<div class="line"><a id="l00138" name="l00138"></a><span class="lineno">  138</span><span class="comment"> *     in a flow-control setup inverted versus the proactor pattern; but ultimately they&#39;re both doing the same thing.</span></div>
<div class="line"><a id="l00139" name="l00139"></a><span class="lineno">  139</span><span class="comment"> *     To integrate such a loop with this async-I/O pattern in Flow-IPC, a little extra work is required:</span></div>
<div class="line"><a id="l00140" name="l00140"></a><span class="lineno">  140</span><span class="comment"> *     - Sometimes event-loop libraries provide this as a built-in feature: a *task queue*.  So a facility similar to</span></div>
<div class="line"><a id="l00141" name="l00141"></a><span class="lineno">  141</span><span class="comment"> *       `post()` above is supplied.  Hence the code above would be adapted to a reactor-pattern loop and end up</span></div>
<div class="line"><a id="l00142" name="l00142"></a><span class="lineno">  142</span><span class="comment"> *       fairly similar: In `F()` do some equivalent to the `post()` in the snippet above.  Internally it&#39;ll set up</span></div>
<div class="line"><a id="l00143" name="l00143"></a><span class="lineno">  143</span><span class="comment"> *       some &quot;interrupter&quot; handle in the central `[e]poll*()` handle-set and cause -- from thread W -- for thread U&#39;s</span></div>
<div class="line"><a id="l00144" name="l00144"></a><span class="lineno">  144</span><span class="comment"> *       poll-wait to wake up.  Otherwise:</span></div>
<div class="line"><a id="l00145" name="l00145"></a><span class="lineno">  145</span><span class="comment"> *     - This task-queue facility can be written with relatively little difficulty.  Essentially it involves</span></div>
<div class="line"><a id="l00146" name="l00146"></a><span class="lineno">  146</span><span class="comment"> *       a simple IPC mechanism, perhaps an anonymous pipe, through which thread-W-invoked `F()`s can</span></div>
<div class="line"><a id="l00147" name="l00147"></a><span class="lineno">  147</span><span class="comment"> *       inform the thread-U poll-wait that it must wake up and handle events, among any others that the poll-wait</span></div>
<div class="line"><a id="l00148" name="l00148"></a><span class="lineno">  148</span><span class="comment"> *       covers.</span></div>
<div class="line"><a id="l00149" name="l00149"></a><span class="lineno">  149</span><span class="comment"> *</span></div>
<div class="line"><a id="l00150" name="l00150"></a><span class="lineno">  150</span><span class="comment"> * So that&#39;s the async-I/O (default) pattern in Flow-IPC.  Generally it is easy to work with -- especially</span></div>
<div class="line"><a id="l00151" name="l00151"></a><span class="lineno">  151</span><span class="comment"> * in a proactor-pattern event loop, but otherwise also not hard.  It cleanly separates Flow-IPC&#39;s internal needs</span></div>
<div class="line"><a id="l00152" name="l00152"></a><span class="lineno">  152</span><span class="comment"> * from the rest of the application&#39;s: Flow-IPC needs to do background work?  It takes care of its own needs:</span></div>
<div class="line"><a id="l00153" name="l00153"></a><span class="lineno">  153</span><span class="comment"> * it starts and ends threads without your participation.  Moreover this may</span></div>
<div class="line"><a id="l00154" name="l00154"></a><span class="lineno">  154</span><span class="comment"> * well help performance of the user&#39;s own event loop: Flow-IPC&#39;s</span></div>
<div class="line"><a id="l00155" name="l00155"></a><span class="lineno">  155</span><span class="comment"> * cycles are mostly spent in separate threads, reducing the length of your loop&#39;s single iteration and thus</span></div>
<div class="line"><a id="l00156" name="l00156"></a><span class="lineno">  156</span><span class="comment"> * helping reduce your latency.  The processors&#39; context-switching is automatic and usually efficient; and it</span></div>
<div class="line"><a id="l00157" name="l00157"></a><span class="lineno">  157</span><span class="comment"> * automatically makes use of multiple hardware cores.</span></div>
<div class="line"><a id="l00158" name="l00158"></a><span class="lineno">  158</span><span class="comment"> *</span></div>
<div class="line"><a id="l00159" name="l00159"></a><span class="lineno">  159</span><span class="comment"> * ### Rationale for the `sync_io` pattern ###</span></div>
<div class="line"><a id="l00160" name="l00160"></a><span class="lineno">  160</span><span class="comment"> * So why might the default pattern described above be insufficient?  A detailed study of this is outside our scope</span></div>
<div class="line"><a id="l00161" name="l00161"></a><span class="lineno">  161</span><span class="comment"> * here; but basically it is a matter of control.  The way it starts threads, in a way that cannot be specified</span></div>
<div class="line"><a id="l00162" name="l00162"></a><span class="lineno">  162</span><span class="comment"> * by you (the user), and switches between them may be helpful in 95% of cases; but some applications want complete</span></div>
<div class="line"><a id="l00163" name="l00163"></a><span class="lineno">  163</span><span class="comment"> * control of any such thing.  For instance suppose I&#39;d like to start with doing all that background work</span></div>
<div class="line"><a id="l00164" name="l00164"></a><span class="lineno">  164</span><span class="comment"> * of `Native_socket_stream::async_receive_blob()` directly in thread U.  It should be possible, right?  Whatever</span></div>
<div class="line"><a id="l00165" name="l00165"></a><span class="lineno">  165</span><span class="comment"> * events it waits on -- in reality, internally, principally it waits for readability of a Unix domain socket --</span></div>
<div class="line"><a id="l00166" name="l00166"></a><span class="lineno">  166</span><span class="comment"> * I could just wait-on in my own thread-U `epoll_wait()`.  When an active event is detected, I could do the</span></div>
<div class="line"><a id="l00167" name="l00167"></a><span class="lineno">  167</span><span class="comment"> * resulting non-blocking-reads -- that normally would be done in the background thread W -- directly after</span></div>
<div class="line"><a id="l00168" name="l00168"></a><span class="lineno">  168</span><span class="comment"> * the poll-wait.</span></div>
<div class="line"><a id="l00169" name="l00169"></a><span class="lineno">  169</span><span class="comment"> *</span></div>
<div class="line"><a id="l00170" name="l00170"></a><span class="lineno">  170</span><span class="comment"> * Maybe that would be good, reducing context-switching overhead.  Or maybe it wouldn&#39;t be good, as a big fat</span></div>
<div class="line"><a id="l00171" name="l00171"></a><span class="lineno">  171</span><span class="comment"> * loop iteration could cause latency in serving the next batch of work.  If so, and I *did* want</span></div>
<div class="line"><a id="l00172" name="l00172"></a><span class="lineno">  172</span><span class="comment"> * to do some of the work in some other thread for parallelization, maybe I want to share that other thread with</span></div>
<div class="line"><a id="l00173" name="l00173"></a><span class="lineno">  173</span><span class="comment"> * some other processing.  Or... or....  Point is: perhaps I want to explicitly structure what threads do what, whether</span></div>
<div class="line"><a id="l00174" name="l00174"></a><span class="lineno">  174</span><span class="comment"> * or not I want multi-threaded processing.</span></div>
<div class="line"><a id="l00175" name="l00175"></a><span class="lineno">  175</span><span class="comment"> *</span></div>
<div class="line"><a id="l00176" name="l00176"></a><span class="lineno">  176</span><span class="comment"> * If that is the case, then the `sync_io` pattern will serve that need.  In this pattern, for example</span></div>
<div class="line"><a id="l00177" name="l00177"></a><span class="lineno">  177</span><span class="comment"> * in transport::sync_io::Native_socket_stream, you&#39;ll notice completion handlers are still used as part of the API.</span></div>
<div class="line"><a id="l00178" name="l00178"></a><span class="lineno">  178</span><span class="comment"> * However, they are *never* invoked in the background: *you* call into a `sync_io::X` API, and it might</span></div>
<div class="line"><a id="l00179" name="l00179"></a><span class="lineno">  179</span><span class="comment"> * *synchronously only* and at very specific points invoke a completion handler `F()` that you supplied it earlier.</span></div>
<div class="line"><a id="l00180" name="l00180"></a><span class="lineno">  180</span><span class="comment"> *</span></div>
<div class="line"><a id="l00181" name="l00181"></a><span class="lineno">  181</span><span class="comment"> * We&#39;ll get into details below, but to summarize how this is integrated with the 2 above-covered user event loop</span></div>
<div class="line"><a id="l00182" name="l00182"></a><span class="lineno">  182</span><span class="comment"> * patterns:</span></div>
<div class="line"><a id="l00183" name="l00183"></a><span class="lineno">  183</span><span class="comment"> *   - Proactor pattern: The `sync_io` pattern in Flow-IPC has first-class support for a boost.asio event loop</span></div>
<div class="line"><a id="l00184" name="l00184"></a><span class="lineno">  184</span><span class="comment"> *     on the user&#39;s part.  So -- basically -- if you&#39;ve got a `boost::asio::io_context E` (`flow::util::Task_engine E`)</span></div>
<div class="line"><a id="l00185" name="l00185"></a><span class="lineno">  185</span><span class="comment"> *     `run()`ning over 1+ threads U, then `sync_io::X` shall give you boost.asio `descriptor` objects associated</span></div>
<div class="line"><a id="l00186" name="l00186"></a><span class="lineno">  186</span><span class="comment"> *     with `E` and ask *you* -- yourself, albeit on its behalf -- to perform `.async_wait(write, G)` or</span></div>
<div class="line"><a id="l00187" name="l00187"></a><span class="lineno">  187</span><span class="comment"> *     `.async_wait(read, G)` on those `descriptor`s; and inform the `sync_io::X` when they&#39;ve completed, inside `G()`.</span></div>
<div class="line"><a id="l00188" name="l00188"></a><span class="lineno">  188</span><span class="comment"> *     As a result, `sync_io::X` internals might inform you of the completion of an `async_...()` op earlier requested</span></div>
<div class="line"><a id="l00189" name="l00189"></a><span class="lineno">  189</span><span class="comment"> *     by you.</span></div>
<div class="line"><a id="l00190" name="l00190"></a><span class="lineno">  190</span><span class="comment"> *   - Reactor pattern: If your loop isn&#39;t boost.asio-based, then `sync_io::X` will similarly ask you to perform</span></div>
<div class="line"><a id="l00191" name="l00191"></a><span class="lineno">  191</span><span class="comment"> *     async-waits on this or that handle for read or write or both, just over a slightly different API -- one</span></div>
<div class="line"><a id="l00192" name="l00192"></a><span class="lineno">  192</span><span class="comment"> *     conducive to `poll()`, `epoll_ctl()`/`epoll_wait()`, and the like.  In short it&#39;ll tell you what FD and what</span></div>
<div class="line"><a id="l00193" name="l00193"></a><span class="lineno">  193</span><span class="comment"> *     event it wants you to wait-on (and again give you function `G()` to call when it is indeed active).</span></div>
<div class="line"><a id="l00194" name="l00194"></a><span class="lineno">  194</span><span class="comment"> *</span></div>
<div class="line"><a id="l00195" name="l00195"></a><span class="lineno">  195</span><span class="comment"> * Thus, *you* control what happens in what thread -- and everything can happen in *your* single thread, if you</span></div>
<div class="line"><a id="l00196" name="l00196"></a><span class="lineno">  196</span><span class="comment"> * so desire.  *You* can create the other threads, arrange necessary synchronization -- including of access to</span></div>
<div class="line"><a id="l00197" name="l00197"></a><span class="lineno">  197</span><span class="comment"> * the `sync_io::X` in question -- as opposed to rely on whatever we&#39;ve internally designed inside non-`sync_io` `X`.</span></div>
<div class="line"><a id="l00198" name="l00198"></a><span class="lineno">  198</span><span class="comment"> * *You* control when a `sync_io::X` does something.  In particular, it is only in a couple of</span></div>
<div class="line"><a id="l00199" name="l00199"></a><span class="lineno">  199</span><span class="comment"> * specific `sync_io::X::*` APIs that a completion handler you gave it can actually be called.  *If* it is called,</span></div>
<div class="line"><a id="l00200" name="l00200"></a><span class="lineno">  200</span><span class="comment"> * it is always called synchronously right then and there, not from some unknown background thread.</span></div>
<div class="line"><a id="l00201" name="l00201"></a><span class="lineno">  201</span><span class="comment"> *</span></div>
<div class="line"><a id="l00202" name="l00202"></a><span class="lineno">  202</span><span class="comment"> * ### So `sync_io`-pattern-implementing APIs will never start threads? ###</span></div>
<div class="line"><a id="l00203" name="l00203"></a><span class="lineno">  203</span><span class="comment"> * Well, they might.  In some cases it&#39;s an internal need that cannot be avoided.  However, when *both* (1) it can be</span></div>
<div class="line"><a id="l00204" name="l00204"></a><span class="lineno">  204</span><span class="comment"> * avoided, *and* (2) performance could possibly be affected, then correct: Flow-IPC will avoid starting a thread and</span></div>
<div class="line"><a id="l00205" name="l00205"></a><span class="lineno">  205</span><span class="comment"> * performing context-switching.  If it&#39;s immaterial for performance in practice, then it absolutely reserves the</span></div>
<div class="line"><a id="l00206" name="l00206"></a><span class="lineno">  206</span><span class="comment"> * right to make background threads, whether for ease of internal implementation or some other reason.  And,</span></div>
<div class="line"><a id="l00207" name="l00207"></a><span class="lineno">  207</span><span class="comment"> * of course, if there&#39;s some blocking API that must be used internally -- and there is simply no choice but to</span></div>
<div class="line"><a id="l00208" name="l00208"></a><span class="lineno">  208</span><span class="comment"> * use that API -- then a thread will need to be started behind the scenes.  We can&#39;t very well block your thread U, so</span></div>
<div class="line"><a id="l00209" name="l00209"></a><span class="lineno">  209</span><span class="comment"> * at that point we do what we must.</span></div>
<div class="line"><a id="l00210" name="l00210"></a><span class="lineno">  210</span><span class="comment"> *</span></div>
<div class="line"><a id="l00211" name="l00211"></a><span class="lineno">  211</span><span class="comment"> * However, even in *that* case, a `sync_io` *API* is still supplied.  This may be helpful to more easily integrate</span></div>
<div class="line"><a id="l00212" name="l00212"></a><span class="lineno">  212</span><span class="comment"> * with your reactor-pattern event loop.  (However, if you have a proactor like boost.asio as your event loop, then</span></div>
<div class="line"><a id="l00213" name="l00213"></a><span class="lineno">  213</span><span class="comment"> * in our view it is unlikely to be helpful in that sense.  At that point you might as well use the async-I/O</span></div>
<div class="line"><a id="l00214" name="l00214"></a><span class="lineno">  214</span><span class="comment"> * alternative API -- unless, again, there is some performance benefit to maintaining greater control of what</span></div>
<div class="line"><a id="l00215" name="l00215"></a><span class="lineno">  215</span><span class="comment"> * part of Flow-IPC executes when from what thread.)</span></div>
<div class="line"><a id="l00216" name="l00216"></a><span class="lineno">  216</span><span class="comment"> *</span></div>
<div class="line"><a id="l00217" name="l00217"></a><span class="lineno">  217</span><span class="comment"> * ### Using the `sync_io` pattern: design rationale ###</span></div>
<div class="line"><a id="l00218" name="l00218"></a><span class="lineno">  218</span><span class="comment"> * Though it will look different and perhaps complex, it is actually at its core similar to other third-party</span></div>
<div class="line"><a id="l00219" name="l00219"></a><span class="lineno">  219</span><span class="comment"> * APIs that require the user to perform async-waits on their behalf.  The most well known example of such an API</span></div>
<div class="line"><a id="l00220" name="l00220"></a><span class="lineno">  220</span><span class="comment"> * is perhaps OpenSSL.  Take `SSL_read()` -- quite similar in spirit to `sync_io`-pattern `x.async_read_blob()`.</span></div>
<div class="line"><a id="l00221" name="l00221"></a><span class="lineno">  221</span><span class="comment"> * When invoked, barring connection-hosing errors, one of 2 things will happen:</span></div>
<div class="line"><a id="l00222" name="l00222"></a><span class="lineno">  222</span><span class="comment"> *   - It will succeed and read 1 or more bytes and return this fact (&quot;no error, I have read N bytes&quot;).</span></div>
<div class="line"><a id="l00223" name="l00223"></a><span class="lineno">  223</span><span class="comment"> *   - It will fail due to would-block, because it either needs the underlying stream socket to be</span></div>
<div class="line"><a id="l00224" name="l00224"></a><span class="lineno">  224</span><span class="comment"> *     readable, or to be writable.  (The latter -- needing writability -- may seem strange for `SSL_read()`,</span></div>
<div class="line"><a id="l00225" name="l00225"></a><span class="lineno">  225</span><span class="comment"> *     but it&#39;s normal: perhaps the connection is in the middle of a cert negotiation, and at this stage needs</span></div>
<div class="line"><a id="l00226" name="l00226"></a><span class="lineno">  226</span><span class="comment"> *     to write something *out* first; and the connection happens to be in such a state as to not be able to write</span></div>
<div class="line"><a id="l00227" name="l00227"></a><span class="lineno">  227</span><span class="comment"> *     bytes to the kernel send buffer at that moment.)</span></div>
<div class="line"><a id="l00228" name="l00228"></a><span class="lineno">  228</span><span class="comment"> *     So it will return either:</span></div>
<div class="line"><a id="l00229" name="l00229"></a><span class="lineno">  229</span><span class="comment"> *     - `SSL_ERROR_WANT_READ` (meaning, &quot;the underlying stream-socket handle (FD) needs to be readable -- call me</span></div>
<div class="line"><a id="l00230" name="l00230"></a><span class="lineno">  230</span><span class="comment"> *       again after you&#39;ve *async-waited* successfully on this *event-of-interest*, and I will try again&quot;); or</span></div>
<div class="line"><a id="l00231" name="l00231"></a><span class="lineno">  231</span><span class="comment"> *     - `SSL_ERROR_WANT_WRITE` (same but needs writability isntead).</span></div>
<div class="line"><a id="l00232" name="l00232"></a><span class="lineno">  232</span><span class="comment"> *</span></div>
<div class="line"><a id="l00233" name="l00233"></a><span class="lineno">  233</span><span class="comment"> * Your application would then internally register interest in FD so-and-so to be readable or writable.  Perhaps</span></div>
<div class="line"><a id="l00234" name="l00234"></a><span class="lineno">  234</span><span class="comment"> * some `SSL_write()` would be interested in another such event simultaneously too.  So then the next time the</span></div>
<div class="line"><a id="l00235" name="l00235"></a><span class="lineno">  235</span><span class="comment"> * event loop came up to the next `poll()` or `epoll_wait()`, you&#39;d indeed wait on these registered events.</span></div>
<div class="line"><a id="l00236" name="l00236"></a><span class="lineno">  236</span><span class="comment"> * If the `SSL_read()`-related event-of-interest was indeed returned as active, your program would know that</span></div>
<div class="line"><a id="l00237" name="l00237"></a><span class="lineno">  237</span><span class="comment"> * fact, based on its own data structures, and know to try `SSL_read()` again.  That time `SSL_read()` might</span></div>
<div class="line"><a id="l00238" name="l00238"></a><span class="lineno">  238</span><span class="comment"> * succeed; or it might require writability again, or readability this time, and would return</span></div>
<div class="line"><a id="l00239" name="l00239"></a><span class="lineno">  239</span><span class="comment"> * `SSL_ERROR_WANT_*` again.  Eventually it&#39;d get what it needs and return success.</span></div>
<div class="line"><a id="l00240" name="l00240"></a><span class="lineno">  240</span><span class="comment"> *</span></div>
<div class="line"><a id="l00241" name="l00241"></a><span class="lineno">  241</span><span class="comment"> * `sync_io` pattern in Flow-IPC is not much different.  It is arguably more complex to use, but there are good</span></div>
<div class="line"><a id="l00242" name="l00242"></a><span class="lineno">  242</span><span class="comment"> * reasons for it.  Namely there are some differences as to our requirements compared to OpenSSL&#39;s.  To wit:</span></div>
<div class="line"><a id="l00243" name="l00243"></a><span class="lineno">  243</span><span class="comment"> *   - For a given operation -- whether it&#39;s `Native_socket_stream::async_receive_blob()` or the even more</span></div>
<div class="line"><a id="l00244" name="l00244"></a><span class="lineno">  244</span><span class="comment"> *     internally complex transport::struc::Channel::expect_msg() -- there will usually be more than 1</span></div>
<div class="line"><a id="l00245" name="l00245"></a><span class="lineno">  245</span><span class="comment"> *     event of interest a time, in fact spread out over more than 1 handle (FD) at a time at that.  Namely</span></div>
<div class="line"><a id="l00246" name="l00246"></a><span class="lineno">  246</span><span class="comment"> *     in addition to readability/writability of the underlying low-level trqnsport, there are timer(s)</span></div>
<div class="line"><a id="l00247" name="l00247"></a><span class="lineno">  247</span><span class="comment"> *     (such as the idle timer -- `idle_timer_run()`); and `struc::Channel` can be configured to have</span></div>
<div class="line"><a id="l00248" name="l00248"></a><span class="lineno">  248</span><span class="comment"> *     2 in-pipes and thus will be async-waiting on 2 FDs&#39; read events.</span></div>
<div class="line"><a id="l00249" name="l00249"></a><span class="lineno">  249</span><span class="comment"> *     - Hence we need to be able to express the desired async-waits to the user in a more flexible way than</span></div>
<div class="line"><a id="l00250" name="l00250"></a><span class="lineno">  250</span><span class="comment"> *       a simple &quot;can&#39;t do it, tell me when my socket is Xable and call me again.&quot;  We have to communicate</span></div>
<div class="line"><a id="l00251" name="l00251"></a><span class="lineno">  251</span><span class="comment"> *       an entire set-of-events-of-interest as well as changes in it over time.</span></div>
<div class="line"><a id="l00252" name="l00252"></a><span class="lineno">  252</span><span class="comment"> *   - OpenSSL is targeted at old-school event loops -- ~all written in the reactor-pattern style.</span></div>
<div class="line"><a id="l00253" name="l00253"></a><span class="lineno">  253</span><span class="comment"> *     Flow-IPC is meant to be usable by modern proactor-pattern applications *and* old-school reactor-pattern</span></div>
<div class="line"><a id="l00254" name="l00254"></a><span class="lineno">  254</span><span class="comment"> *     ones as well.  It would be unfortunate, in particular, if a given `X` is written in the modern handler-based way,</span></div>
<div class="line"><a id="l00255" name="l00255"></a><span class="lineno">  255</span><span class="comment"> *     while `X::sync_io` counterpart is just entirely different.  In fact, suppose `sync_io::X` is available;</span></div>
<div class="line"><a id="l00256" name="l00256"></a><span class="lineno">  256</span><span class="comment"> *     *our* `X` internally &quot;wants&quot; to be written around a boost.asio loop *and* reuse `sync_io::X` internally</span></div>
<div class="line"><a id="l00257" name="l00257"></a><span class="lineno">  257</span><span class="comment"> *     as well.  So in other words, both aesthetically and practically, an OpenSSL-style old-school API would be</span></div>
<div class="line"><a id="l00258" name="l00258"></a><span class="lineno">  258</span><span class="comment"> *     a pain to use in a boost.asio-based application (our own async-I/O-pattern classes being a good test case).</span></div>
<div class="line"><a id="l00259" name="l00259"></a><span class="lineno">  259</span><span class="comment"> *</span></div>
<div class="line"><a id="l00260" name="l00260"></a><span class="lineno">  260</span><span class="comment"> * Therefore the `sync_io` pattern is strongly inspired by the boost.asio proactor pattern API.  As a corollary it</span></div>
<div class="line"><a id="l00261" name="l00261"></a><span class="lineno">  261</span><span class="comment"> * provides special support for the case when the user&#39;s event loop *is* boost.asio-based.  If your event loop</span></div>
<div class="line"><a id="l00262" name="l00262"></a><span class="lineno">  262</span><span class="comment"> * is old-school, you will lose nothing however -- just don&#39;t use that feature.</span></div>
<div class="line"><a id="l00263" name="l00263"></a><span class="lineno">  263</span><span class="comment"> *</span></div>
<div class="line"><a id="l00264" name="l00264"></a><span class="lineno">  264</span><span class="comment"> * ### Using the `sync_io` pattern: how-to ###</span></div>
<div class="line"><a id="l00265" name="l00265"></a><span class="lineno">  265</span><span class="comment"> * Take `x.async_receive_blob(..., F)`.  If `x` is an `X`, we&#39;ve already described it.  Now let `x` be a `sync_io::X`.</span></div>
<div class="line"><a id="l00266" name="l00266"></a><span class="lineno">  266</span><span class="comment"> * The good news is initiating the same operation uses *almost* the exact same signature.  It takes the same arguments</span></div>
<div class="line"><a id="l00267" name="l00267"></a><span class="lineno">  267</span><span class="comment"> * including a completion handler `F()` with the exact same signature itself.  There is however one difference:</span></div>
<div class="line"><a id="l00268" name="l00268"></a><span class="lineno">  268</span><span class="comment"> * if `F()` takes 1+ args (1st one usually `const Error_code&amp; err_code`; followed at times by something like</span></div>
<div class="line"><a id="l00269" name="l00269"></a><span class="lineno">  269</span><span class="comment"> * `size_t sz` indicating how many bytes were transferred) -- then the `sync_io` form of the `async_...()` method</span></div>
<div class="line"><a id="l00270" name="l00270"></a><span class="lineno">  270</span><span class="comment"> * shall take `sync_`-prefixed *out-arg* counterparts to those args directly as well.  Thus specifically:</span></div>
<div class="line"><a id="l00271" name="l00271"></a><span class="lineno">  271</span><span class="comment"> *   - If async-I/O sig is `x.async_receive_blob(..., F)`,</span></div>
<div class="line"><a id="l00272" name="l00272"></a><span class="lineno">  272</span><span class="comment"> *     where `F()` is of form `void (const Error_code&amp; err_code, size_t sz)`, then:</span></div>
<div class="line"><a id="l00273" name="l00273"></a><span class="lineno">  273</span><span class="comment"> *   - `sync_io` sig is: `x.async_receive_blob(..., Error_code* sync_err_code, size_t* sync_sz, F)`,</span></div>
<div class="line"><a id="l00274" name="l00274"></a><span class="lineno">  274</span><span class="comment"> *     where `F()` is of the same form as before.  You shall provide `&amp;sync_err_code, &amp;sync_sz`, and your local</span></div>
<div class="line"><a id="l00275" name="l00275"></a><span class="lineno">  275</span><span class="comment"> *     variables shall be set to certain values upon return.</span></div>
<div class="line"><a id="l00276" name="l00276"></a><span class="lineno">  276</span><span class="comment"> *     - You may also leave `sync_err_code` (if applicable) null.  In that case standard Flow error-reporting</span></div>
<div class="line"><a id="l00277" name="l00277"></a><span class="lineno">  277</span><span class="comment"> *       semantics are active: if (and only if) `*sync_err_code` *would* be set to truthy (non-success) value,</span></div>
<div class="line"><a id="l00278" name="l00278"></a><span class="lineno">  278</span><span class="comment"> *       but `sync_err_code` is a null pointer, then a `flow::error::Runtime_error` is thrown with</span></div>
<div class="line"><a id="l00279" name="l00279"></a><span class="lineno">  279</span><span class="comment"> *       the would be `*sync_err_code` stored inside the exception object (and a message in its `.what()`).</span></div>
<div class="line"><a id="l00280" name="l00280"></a><span class="lineno">  280</span><span class="comment"> *</span></div>
<div class="line"><a id="l00281" name="l00281"></a><span class="lineno">  281</span><span class="comment"> * So let&#39;s say you call `sync_io` `x.async_receive_blob()`, providing it `&amp;sync_err_code, &amp;sz` args, otherwise</span></div>
<div class="line"><a id="l00282" name="l00282"></a><span class="lineno">  282</span><span class="comment"> * using the same arg values as with async-I/O.  (For simplicity of discussion let&#39;s assume you did not pass</span></div>
<div class="line"><a id="l00283" name="l00283"></a><span class="lineno">  283</span><span class="comment"> * null pointer for the sync-err-code arg.)  Then: `F()` will no longer</span></div>
<div class="line"><a id="l00284" name="l00284"></a><span class="lineno">  284</span><span class="comment"> * execute from some unspecified thread at some unknown future time.  Instead there are 2 possibilities.</span></div>
<div class="line"><a id="l00285" name="l00285"></a><span class="lineno">  285</span><span class="comment"> *   - If `x.async_receive_blob()` was able to receive a message (more generally -- complete the operation)</span></div>
<div class="line"><a id="l00286" name="l00286"></a><span class="lineno">  286</span><span class="comment"> *     synchronously (immediately), then:</span></div>
<div class="line"><a id="l00287" name="l00287"></a><span class="lineno">  287</span><span class="comment"> *     - The method *itself* shall emit (via `sync_err_code` out-arg) either *no* error (falsy value)</span></div>
<div class="line"><a id="l00288" name="l00288"></a><span class="lineno">  288</span><span class="comment"> *       or an error (truthy value) that is specifically *not* ipc::transport::error::Code::S_SYNC_IO_WOULD_BLOCK.</span></div>
<div class="line"><a id="l00289" name="l00289"></a><span class="lineno">  289</span><span class="comment"> *       - This is quite analogous to `SSL_read()` succeeding immediately, without `SSL_ERROR_WANT_*`.</span></div>
<div class="line"><a id="l00290" name="l00290"></a><span class="lineno">  290</span><span class="comment"> *     - The method *itself* shall synchronously emit other `sync_` out-arg values indicating the result</span></div>
<div class="line"><a id="l00291" name="l00291"></a><span class="lineno">  291</span><span class="comment"> *       of the operation.  In this case that is `sync_sz == 0` on error, or `sync_sz &gt; 0` indicating how many</span></div>
<div class="line"><a id="l00292" name="l00292"></a><span class="lineno">  292</span><span class="comment"> *       bytes long the successfully, *synchronously* received blob is.</span></div>
<div class="line"><a id="l00293" name="l00293"></a><span class="lineno">  293</span><span class="comment"> *       - Again: This is quite analogous to `SSL_read()` succeeding immediately, without `SSL_ERROR_WANT_*`.</span></div>
<div class="line"><a id="l00294" name="l00294"></a><span class="lineno">  294</span><span class="comment"> *     - The async completion handler, `F`, shall be utterly and completely ignored.  It will *not* be saved.</span></div>
<div class="line"><a id="l00295" name="l00295"></a><span class="lineno">  295</span><span class="comment"> *       It will *not* be called.  The operation already finished: you get to deal with it right then and there</span></div>
<div class="line"><a id="l00296" name="l00296"></a><span class="lineno">  296</span><span class="comment"> *       like a normal synchronous human being.</span></div>
<div class="line"><a id="l00297" name="l00297"></a><span class="lineno">  297</span><span class="comment"> *   - Conversely, if `x.async_receive_blob()` can only complete the op after some events-of-interest (to `x`)</span></div>
<div class="line"><a id="l00298" name="l00298"></a><span class="lineno">  298</span><span class="comment"> *     become active (we&#39;ll discuss how this works in a moment) -- then:</span></div>
<div class="line"><a id="l00299" name="l00299"></a><span class="lineno">  299</span><span class="comment"> *     - The method *itself* shall emit (via `sync_err_code` out-arg) the specific code</span></div>
<div class="line"><a id="l00300" name="l00300"></a><span class="lineno">  300</span><span class="comment"> *       ipc::transport::error::Code::S_SYNC_IO_WOULD_BLOCK.</span></div>
<div class="line"><a id="l00301" name="l00301"></a><span class="lineno">  301</span><span class="comment"> *       - This is analogous to `SSL_read()` returning `SSL_ERROR_WANT_*`.</span></div>
<div class="line"><a id="l00302" name="l00302"></a><span class="lineno">  302</span><span class="comment"> *     - It shall save `F` internally inside `x`.</span></div>
<div class="line"><a id="l00303" name="l00303"></a><span class="lineno">  303</span><span class="comment"> *     - Later, when your loop *does* detect an event-of-interest (to `x`) is active, it shall explicitly</span></div>
<div class="line"><a id="l00304" name="l00304"></a><span class="lineno">  304</span><span class="comment"> *       *call into another `x` API method* -- we call it `(*on_active_ev_func)()` -- and *that* method may</span></div>
<div class="line"><a id="l00305" name="l00305"></a><span class="lineno">  305</span><span class="comment"> *       *synchronously* invoke the memorized completion handler `F()`.  In the case of `x.async_receive_blob()`</span></div>
<div class="line"><a id="l00306" name="l00306"></a><span class="lineno">  306</span><span class="comment"> *       this `F()` call will be just as you&#39;re used-to with async-I/O pattern:</span></div>
<div class="line"><a id="l00307" name="l00307"></a><span class="lineno">  307</span><span class="comment"> *       `err_code` truthy on error, `sz == 0`; or `err_code` falsy on success, `sz &gt; 0` indicating size of</span></div>
<div class="line"><a id="l00308" name="l00308"></a><span class="lineno">  308</span><span class="comment"> *       received blob.</span></div>
<div class="line"><a id="l00309" name="l00309"></a><span class="lineno">  309</span><span class="comment"> *       - Since `x.async_receive_blob()` has one-off completion handler semantics, at this point it&#39;ll forget `F`.</span></div>
<div class="line"><a id="l00310" name="l00310"></a><span class="lineno">  310</span><span class="comment"> *       - However, with `sync_io` pattern, `x` shall *never* issue an operation-aborted call to `F()` or</span></div>
<div class="line"><a id="l00311" name="l00311"></a><span class="lineno">  311</span><span class="comment"> *         `x` destruction or anything like that.  That&#39;s an async-I/O thing.</span></div>
<div class="line"><a id="l00312" name="l00312"></a><span class="lineno">  312</span><span class="comment"> *</span></div>
<div class="line"><a id="l00313" name="l00313"></a><span class="lineno">  313</span><span class="comment"> * The &quot;later, when your loop&quot; step is analogous to: your loop awaiting an event as asked by the would-block</span></div>
<div class="line"><a id="l00314" name="l00314"></a><span class="lineno">  314</span><span class="comment"> * `SSL_read()`, then once active calling `SSL_read()` again; and the latter, this time, returning success.</span></div>
<div class="line"><a id="l00315" name="l00315"></a><span class="lineno">  315</span><span class="comment"> * Note, however, that you do *not* re-call `x.async_receive_blob()` on the desired active event.  Conceptually</span></div>
<div class="line"><a id="l00316" name="l00316"></a><span class="lineno">  316</span><span class="comment"> * you&#39;re doing the same thing -- you&#39;re saying, &quot;the event you wanted is ready; if you can get what I wanted</span></div>
<div class="line"><a id="l00317" name="l00317"></a><span class="lineno">  317</span><span class="comment"> * then do it now&quot; -- but you&#39;re doing it by using a separate API.</span></div>
<div class="line"><a id="l00318" name="l00318"></a><span class="lineno">  318</span><span class="comment"> *</span></div>
<div class="line"><a id="l00319" name="l00319"></a><span class="lineno">  319</span><span class="comment"> * That leaves the other other major piece of the API: how to in fact be informed of a desired event-of-interest</span></div>
<div class="line"><a id="l00320" name="l00320"></a><span class="lineno">  320</span><span class="comment"> * and subsequently indicate that event-of-interest is indeed active.  In terms of the API, this procedure is</span></div>
<div class="line"><a id="l00321" name="l00321"></a><span class="lineno">  321</span><span class="comment"> * decoupled from the actual `x.async_receive_blob()` API.  Moreover it is not expressed as some kind of big</span></div>
<div class="line"><a id="l00322" name="l00322"></a><span class="lineno">  322</span><span class="comment"> * set-of-handles-and-events-in-which-`x`-has-interest-at-a-given-time either.  Instead, conceptually, it is</span></div>
<div class="line"><a id="l00323" name="l00323"></a><span class="lineno">  323</span><span class="comment"> * expressed similarly to boost.asio: `x` says to itself: I want to do</span></div>
<div class="line"><a id="l00324" name="l00324"></a><span class="lineno">  324</span><span class="comment"> * `handle_so_and_so.async_wait(readable, F)`; or: I want to do</span></div>
<div class="line"><a id="l00325" name="l00325"></a><span class="lineno">  325</span><span class="comment"> * `handle_so_and_so.async_wait(writable, F)`.  But since `handle_so_and_so` is not a boost.asio I/O object, it has</span></div>
<div class="line"><a id="l00326" name="l00326"></a><span class="lineno">  326</span><span class="comment"> * to express the same thing to the user of `x`.  How?  Answer: sync_io::Event_wait_func.  Its doc header explains</span></div>
<div class="line"><a id="l00327" name="l00327"></a><span class="lineno">  327</span><span class="comment"> * the details.  We summarize for our chosen example of `x.async_receive_blob()`:</span></div>
<div class="line"><a id="l00328" name="l00328"></a><span class="lineno">  328</span><span class="comment"> *   - Just after constructing the `x`, set up the async-wait function: `x.start_receive_blob_ops(E)`,</span></div>
<div class="line"><a id="l00329" name="l00329"></a><span class="lineno">  329</span><span class="comment"> *     where `E` is a function with signature a-la `Event_wait_func`.</span></div>
<div class="line"><a id="l00330" name="l00330"></a><span class="lineno">  330</span><span class="comment"> *     - (Note that `receive_blob` fragment of the method name.  This is replaced with other fragments for other</span></div>
<div class="line"><a id="l00331" name="l00331"></a><span class="lineno">  331</span><span class="comment"> *       operations.  In some cases an object -- ipc::transport::Native_socket_stream being a prime example -- supports</span></div>
<div class="line"><a id="l00332" name="l00332"></a><span class="lineno">  332</span><span class="comment"> *       2+ sets of operations.  For example `Native_socket_stream::start_send_blob_ops()` is for the *independent*</span></div>
<div class="line"><a id="l00333" name="l00333"></a><span class="lineno">  333</span><span class="comment"> *       outgoing-direction operations that can occur *concurrently to* incoming-direction `start_receive_blob_ops()`</span></div>
<div class="line"><a id="l00334" name="l00334"></a><span class="lineno">  334</span><span class="comment"> *       ops.)</span></div>
<div class="line"><a id="l00335" name="l00335"></a><span class="lineno">  335</span><span class="comment"> *       No need to worry about that for now though; we continue with our `receive_blob` example use case.</span></div>
<div class="line"><a id="l00336" name="l00336"></a><span class="lineno">  336</span><span class="comment"> *   - *If* (and only if!) your event loop is boost.asio-based, then precede this call with one that supplies</span></div>
<div class="line"><a id="l00337" name="l00337"></a><span class="lineno">  337</span><span class="comment"> *     the boost.asio `Task_engine` (or strand or...) where you do your async work: `.replace_event_wait_handles()`.</span></div>
<div class="line"><a id="l00338" name="l00338"></a><span class="lineno">  338</span><span class="comment"> *</span></div>
<div class="line"><a id="l00339" name="l00339"></a><span class="lineno">  339</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00340" name="l00340"></a><span class="lineno">  340</span><span class="comment"> *   using ipc::util::sync_io::Task_ptr;</span></div>
<div class="line"><a id="l00341" name="l00341"></a><span class="lineno">  341</span><span class="comment"> *   using ipc::util::sync_io::Asio_waitable_native_handle;</span></div>
<div class="line"><a id="l00342" name="l00342"></a><span class="lineno">  342</span><span class="comment"> *</span></div>
<div class="line"><a id="l00343" name="l00343"></a><span class="lineno">  343</span><span class="comment"> *   x.replace_event_wait_handles</span></div>
<div class="line"><a id="l00344" name="l00344"></a><span class="lineno">  344</span><span class="comment"> *     ([this]() -&gt; auto { return Asio_waitable_native_handle(m_my_task_engine); });</span></div>
<div class="line"><a id="l00345" name="l00345"></a><span class="lineno">  345</span><span class="comment"> *   x.start_receive_blob_ops([this](Asio_waitable_native_handle* hndl_of_interest,</span></div>
<div class="line"><a id="l00346" name="l00346"></a><span class="lineno">  346</span><span class="comment"> *                                   bool ev_of_interest_snd_else_rcv,</span></div>
<div class="line"><a id="l00347" name="l00347"></a><span class="lineno">  347</span><span class="comment"> *                                   Task_ptr&amp;&amp; on_active_ev_func)</span></div>
<div class="line"><a id="l00348" name="l00348"></a><span class="lineno">  348</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00349" name="l00349"></a><span class="lineno">  349</span><span class="comment"> *     my_rcv_blob_sync_io_ev_wait(hndl_of_interest, ev_of_interest_snd_else_rcv, std::move(on_active_ev_func));</span></div>
<div class="line"><a id="l00350" name="l00350"></a><span class="lineno">  350</span><span class="comment"> *   });</span></div>
<div class="line"><a id="l00351" name="l00351"></a><span class="lineno">  351</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00352" name="l00352"></a><span class="lineno">  352</span><span class="comment"> *</span></div>
<div class="line"><a id="l00353" name="l00353"></a><span class="lineno">  353</span><span class="comment"> * We are now ready for the last sub-piece: named `my_rcv_blob_sync_io_ev_wait()` in that snippet.  This key piece</span></div>
<div class="line"><a id="l00354" name="l00354"></a><span class="lineno">  354</span><span class="comment"> * responds to the instruction: async-wait for the specified event for me please, and let me know when that event</span></div>
<div class="line"><a id="l00355" name="l00355"></a><span class="lineno">  355</span><span class="comment"> * is active by calling `(*on_active_ev_func)()` at that time.  The details of how exactly to do this can be</span></div>
<div class="line"><a id="l00356" name="l00356"></a><span class="lineno">  356</span><span class="comment"> * found in the sync_io::Event_wait_func doc header -- including tips on integrating with `poll()` and `epoll_*()`.</span></div>
<div class="line"><a id="l00357" name="l00357"></a><span class="lineno">  357</span><span class="comment"> * Here we will assume you have a boost.asio loop, continuing from the above snippet.  The simplest possible</span></div>
<div class="line"><a id="l00358" name="l00358"></a><span class="lineno">  358</span><span class="comment"> * continuation:</span></div>
<div class="line"><a id="l00359" name="l00359"></a><span class="lineno">  359</span><span class="comment"> *</span></div>
<div class="line"><a id="l00360" name="l00360"></a><span class="lineno">  360</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00361" name="l00361"></a><span class="lineno">  361</span><span class="comment"> *   void my_rcv_blob_sync_io_ev_wait(Asio_waitable_native_handle* hndl_of_interest,</span></div>
<div class="line"><a id="l00362" name="l00362"></a><span class="lineno">  362</span><span class="comment"> *                                    bool ev_of_interest_snd_else_rcv,</span></div>
<div class="line"><a id="l00363" name="l00363"></a><span class="lineno">  363</span><span class="comment"> *                                    Task_ptr&amp;&amp; on_active_ev_func)</span></div>
<div class="line"><a id="l00364" name="l00364"></a><span class="lineno">  364</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00365" name="l00365"></a><span class="lineno">  365</span><span class="comment"> *     // sync_io wants us to async-wait.  Oblige.</span></div>
<div class="line"><a id="l00366" name="l00366"></a><span class="lineno">  366</span><span class="comment"> *     hndl_of_interest-&gt;async_wait(ev_of_interest_snd_else_rcv</span></div>
<div class="line"><a id="l00367" name="l00367"></a><span class="lineno">  367</span><span class="comment"> *                                    ? Asio_waitable_native_handle::Base::wait_write</span></div>
<div class="line"><a id="l00368" name="l00368"></a><span class="lineno">  368</span><span class="comment"> *                                    : Asio_waitable_native_handle::Base::wait_read,</span></div>
<div class="line"><a id="l00369" name="l00369"></a><span class="lineno">  369</span><span class="comment"> *                                  [this, on_active_ev_func = std::move(on_active_ev_func)]</span></div>
<div class="line"><a id="l00370" name="l00370"></a><span class="lineno">  370</span><span class="comment"> *                                    (const Error_code&amp; err_code)</span></div>
<div class="line"><a id="l00371" name="l00371"></a><span class="lineno">  371</span><span class="comment"> *     {</span></div>
<div class="line"><a id="l00372" name="l00372"></a><span class="lineno">  372</span><span class="comment"> *       if (err_code == boost::asio::error::operation_aborted) { return; } // Shutting down?  Get out.</span></div>
<div class="line"><a id="l00373" name="l00373"></a><span class="lineno">  373</span><span class="comment"> *</span></div>
<div class="line"><a id="l00374" name="l00374"></a><span class="lineno">  374</span><span class="comment"> *       // Event is active.  sync_io wants us to inform it of this.  Oblige.</span></div>
<div class="line"><a id="l00375" name="l00375"></a><span class="lineno">  375</span><span class="comment"> *       (*on_active_ev_func)();</span></div>
<div class="line"><a id="l00376" name="l00376"></a><span class="lineno">  376</span><span class="comment"> *       // ^-- THAT POTENTIALLY INVOKED COMPLETION HANDLER F() WE PASS IN TO x.async_receive_blob(F)!!!</span></div>
<div class="line"><a id="l00377" name="l00377"></a><span class="lineno">  377</span><span class="comment"> *     });</span></div>
<div class="line"><a id="l00378" name="l00378"></a><span class="lineno">  378</span><span class="comment"> *   }</span></div>
<div class="line"><a id="l00379" name="l00379"></a><span class="lineno">  379</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00380" name="l00380"></a><span class="lineno">  380</span><span class="comment"> *</span></div>
<div class="line"><a id="l00381" name="l00381"></a><span class="lineno">  381</span><span class="comment"> * That&#39;s it.  Note well: `(*on_active_ev_func)()` is (a) informing `sync_io`-pattern-implementing `x` of the</span></div>
<div class="line"><a id="l00382" name="l00382"></a><span class="lineno">  382</span><span class="comment"> * event it (`x`) wanted; and (b) possibly getting the result *you* wanted in the original `async_receive_*()` call.</span></div>
<div class="line"><a id="l00383" name="l00383"></a><span class="lineno">  383</span><span class="comment"> * Thus it is the equivalent of the 2nd `SSL_read()` call, after satisying the `SSL_ERROR_WANT_READ` or</span></div>
<div class="line"><a id="l00384" name="l00384"></a><span class="lineno">  384</span><span class="comment"> * `SSL_ERROR_WANT_WRITE` result.  The only difference, really, is the mechanic of getting the result is through</span></div>
<div class="line"><a id="l00385" name="l00385"></a><span class="lineno">  385</span><span class="comment"> * a *synchronous* call to your completion handler.</span></div>
<div class="line"><a id="l00386" name="l00386"></a><span class="lineno">  386</span><span class="comment"> *</span></div>
<div class="line"><a id="l00387" name="l00387"></a><span class="lineno">  387</span><span class="comment"> * There is, however, an extremely important subtlety to consider additionally.  The key point:</span></div>
<div class="line"><a id="l00388" name="l00388"></a><span class="lineno">  388</span><span class="comment"> *   - `(*on_active_ev_func)()` should be thought of as an API -- a method! -- of `x`, the</span></div>
<div class="line"><a id="l00389" name="l00389"></a><span class="lineno">  389</span><span class="comment"> *     `sync_io`-pattern-implementing Flow-IPC object...</span></div>
<div class="line"><a id="l00390" name="l00390"></a><span class="lineno">  390</span><span class="comment"> *   - ...right alongside (in our use case here) `.async_receive_blob()`.</span></div>
<div class="line"><a id="l00391" name="l00391"></a><span class="lineno">  391</span><span class="comment"> *</span></div>
<div class="line"><a id="l00392" name="l00392"></a><span class="lineno">  392</span><span class="comment"> * That means it is *not* thread-safe to call `(*on_active_ev_func)()` concurrently with</span></div>
<div class="line"><a id="l00393" name="l00393"></a><span class="lineno">  393</span><span class="comment"> * `x.async_receive_blob()`.  What does this mean in practice?  Answer:</span></div>
<div class="line"><a id="l00394" name="l00394"></a><span class="lineno">  394</span><span class="comment"> *   - If you execute all these things in a single-threaded event loop -- nothing.  You need not worry about</span></div>
<div class="line"><a id="l00395" name="l00395"></a><span class="lineno">  395</span><span class="comment"> *     synchronization.</span></div>
<div class="line"><a id="l00396" name="l00396"></a><span class="lineno">  396</span><span class="comment"> *   - If you perform some of your work on `x` (perhaps the `.async_*()` calls) in one thread but</span></div>
<div class="line"><a id="l00397" name="l00397"></a><span class="lineno">  397</span><span class="comment"> *     the async-wait handling -- and the potentially resulting *synchronous* invocation of your own completion</span></div>
<div class="line"><a id="l00398" name="l00398"></a><span class="lineno">  398</span><span class="comment"> *     handlers -- in another...</span></div>
<div class="line"><a id="l00399" name="l00399"></a><span class="lineno">  399</span><span class="comment"> *     - ...then you, at a minimum, need a mutex-lock (or use of a strand, or ...) around the call sites into</span></div>
<div class="line"><a id="l00400" name="l00400"></a><span class="lineno">  400</span><span class="comment"> *       `x.method(...)`, for all related `method`s of `x`...</span></div>
<div class="line"><a id="l00401" name="l00401"></a><span class="lineno">  401</span><span class="comment"> *     - ...*including* the call to `(*on_active_ev_func)()`.</span></div>
<div class="line"><a id="l00402" name="l00402"></a><span class="lineno">  402</span><span class="comment"> *</span></div>
<div class="line"><a id="l00403" name="l00403"></a><span class="lineno">  403</span><span class="comment"> * Chances are, though, that if you&#39;re operating in multiple threads, then anyway you&#39;ll need to protect *your own*</span></div>
<div class="line"><a id="l00404" name="l00404"></a><span class="lineno">  404</span><span class="comment"> * data structures against concurrent writing.  Remember: `(*on_active_ev_func)()` may well invoke</span></div>
<div class="line"><a id="l00405" name="l00405"></a><span class="lineno">  405</span><span class="comment"> * *your own completion handler* from the original `x.async_receive_blob(..., F)` call.  That code (*your* code)</span></div>
<div class="line"><a id="l00406" name="l00406"></a><span class="lineno">  406</span><span class="comment"> * is more than likely to react to the received payload in some way, and that might be touching data structures</span></div>
<div class="line"><a id="l00407" name="l00407"></a><span class="lineno">  407</span><span class="comment"> * accessed from 2+ threads.  It would therefore make sense that the relevant mutex be already locked.  In this</span></div>
<div class="line"><a id="l00408" name="l00408"></a><span class="lineno">  408</span><span class="comment"> * example we presuppose your application might invoke async-receives from a thread U while placing handlers</span></div>
<div class="line"><a id="l00409" name="l00409"></a><span class="lineno">  409</span><span class="comment"> * onto a thread W:</span></div>
<div class="line"><a id="l00410" name="l00410"></a><span class="lineno">  410</span><span class="comment"> *</span></div>
<div class="line"><a id="l00411" name="l00411"></a><span class="lineno">  411</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00412" name="l00412"></a><span class="lineno">  412</span><span class="comment"> *   using flow::util::Lock_guard;</span></div>
<div class="line"><a id="l00413" name="l00413"></a><span class="lineno">  413</span><span class="comment"> *</span></div>
<div class="line"><a id="l00414" name="l00414"></a><span class="lineno">  414</span><span class="comment"> *   ...</span></div>
<div class="line"><a id="l00415" name="l00415"></a><span class="lineno">  415</span><span class="comment"> *     // In your thread U:</span></div>
<div class="line"><a id="l00416" name="l00416"></a><span class="lineno">  416</span><span class="comment"> *</span></div>
<div class="line"><a id="l00417" name="l00417"></a><span class="lineno">  417</span><span class="comment"> *     Lock_guard&lt;decltype(m_my_rcv_mutex)&gt; lock(m_my_rcv_mutex); // &lt;-- ATTN!  Protects x receive ops at least.</span></div>
<div class="line"><a id="l00418" name="l00418"></a><span class="lineno">  418</span><span class="comment"> *     ...</span></div>
<div class="line"><a id="l00419" name="l00419"></a><span class="lineno">  419</span><span class="comment"> *     ipc::Error_code sync_err_code;</span></div>
<div class="line"><a id="l00420" name="l00420"></a><span class="lineno">  420</span><span class="comment"> *     size_t sync_sz;</span></div>
<div class="line"><a id="l00421" name="l00421"></a><span class="lineno">  421</span><span class="comment"> *     x.async_receive_blob(m_target_msg,</span></div>
<div class="line"><a id="l00422" name="l00422"></a><span class="lineno">  422</span><span class="comment"> *                          &amp;sync_err_code, &amp;sync_sz,</span></div>
<div class="line"><a id="l00423" name="l00423"></a><span class="lineno">  423</span><span class="comment"> *                          [this](const ipc::Error_code&amp; err_code, size_t sz) { on_msg_in(err_code, sz); });</span></div>
<div class="line"><a id="l00424" name="l00424"></a><span class="lineno">  424</span><span class="comment"> *     if (sync_err_code != ipc::transport::error::Code::S_SYNC_IO_WOULD_BLOCK)</span></div>
<div class="line"><a id="l00425" name="l00425"></a><span class="lineno">  425</span><span class="comment"> *     {</span></div>
<div class="line"><a id="l00426" name="l00426"></a><span class="lineno">  426</span><span class="comment"> *       // ...Handle contents of m_target_msg, or sync_err_code indicating error ion -- perhaps ~like on_msg_in()!</span></div>
<div class="line"><a id="l00427" name="l00427"></a><span class="lineno">  427</span><span class="comment"> *       // Note m_my_rcv_mutex is locked... as it would be in on_msg_in() (which won&#39;t run in this case)!</span></div>
<div class="line"><a id="l00428" name="l00428"></a><span class="lineno">  428</span><span class="comment"> *     }</span></div>
<div class="line"><a id="l00429" name="l00429"></a><span class="lineno">  429</span><span class="comment"> *     // else { on_msg_in() will run later.  x.receive_...() probably invoked my_rcv_blob_sync_io_ev_wait(). }</span></div>
<div class="line"><a id="l00430" name="l00430"></a><span class="lineno">  430</span><span class="comment"> *   ...</span></div>
<div class="line"><a id="l00431" name="l00431"></a><span class="lineno">  431</span><span class="comment"> *</span></div>
<div class="line"><a id="l00432" name="l00432"></a><span class="lineno">  432</span><span class="comment"> *   void my_rcv_blob_sync_io_ev_wait(Asio_waitable_native_handle* hndl_of_interest,</span></div>
<div class="line"><a id="l00433" name="l00433"></a><span class="lineno">  433</span><span class="comment"> *                                    bool ev_of_interest_snd_else_rcv,</span></div>
<div class="line"><a id="l00434" name="l00434"></a><span class="lineno">  434</span><span class="comment"> *                                    Task_ptr&amp;&amp; on_active_ev_func)</span></div>
<div class="line"><a id="l00435" name="l00435"></a><span class="lineno">  435</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00436" name="l00436"></a><span class="lineno">  436</span><span class="comment"> *     // In your thread U:</span></div>
<div class="line"><a id="l00437" name="l00437"></a><span class="lineno">  437</span><span class="comment"> *</span></div>
<div class="line"><a id="l00438" name="l00438"></a><span class="lineno">  438</span><span class="comment"> *     // sync_io wants us to async-wait.  Oblige.  (Do not lock m_my_rcv_mutex!)</span></div>
<div class="line"><a id="l00439" name="l00439"></a><span class="lineno">  439</span><span class="comment"> *     hndl_of_interest-&gt;async_wait(ev_of_interest_snd_else_rcv</span></div>
<div class="line"><a id="l00440" name="l00440"></a><span class="lineno">  440</span><span class="comment"> *                                    ? Asio_waitable_native_handle::Base::wait_write</span></div>
<div class="line"><a id="l00441" name="l00441"></a><span class="lineno">  441</span><span class="comment"> *                                    : Asio_waitable_native_handle::Base::wait_read,</span></div>
<div class="line"><a id="l00442" name="l00442"></a><span class="lineno">  442</span><span class="comment"> *                                  [this, on_active_ev_func = std::move(on_active_ev_func)]</span></div>
<div class="line"><a id="l00443" name="l00443"></a><span class="lineno">  443</span><span class="comment"> *                                    (const Error_code&amp; err_code)</span></div>
<div class="line"><a id="l00444" name="l00444"></a><span class="lineno">  444</span><span class="comment"> *     {</span></div>
<div class="line"><a id="l00445" name="l00445"></a><span class="lineno">  445</span><span class="comment"> *       if (err_code == boost::asio::error::operation_aborted) { return; } // Shutting down?  Get out.</span></div>
<div class="line"><a id="l00446" name="l00446"></a><span class="lineno">  446</span><span class="comment"> *</span></div>
<div class="line"><a id="l00447" name="l00447"></a><span class="lineno">  447</span><span class="comment"> *       // In your thread W:</span></div>
<div class="line"><a id="l00448" name="l00448"></a><span class="lineno">  448</span><span class="comment"> *</span></div>
<div class="line"><a id="l00449" name="l00449"></a><span class="lineno">  449</span><span class="comment"> *       // Event is active.  sync_io wants to inform it of this.  Oblige.</span></div>
<div class="line"><a id="l00450" name="l00450"></a><span class="lineno">  450</span><span class="comment"> *</span></div>
<div class="line"><a id="l00451" name="l00451"></a><span class="lineno">  451</span><span class="comment"> *       flow::util::Lock_guard&lt;decltype(m_my_rcv_mutex)&gt; lock(m_my_rcv_mutex); // &lt;-- ATTN!</span></div>
<div class="line"><a id="l00452" name="l00452"></a><span class="lineno">  452</span><span class="comment"> *</span></div>
<div class="line"><a id="l00453" name="l00453"></a><span class="lineno">  453</span><span class="comment"> *       (*on_active_ev_func)();</span></div>
<div class="line"><a id="l00454" name="l00454"></a><span class="lineno">  454</span><span class="comment"> *       // ^-- THAT POTENTIALLY INVOKED on_msg_in()!!!</span></div>
<div class="line"><a id="l00455" name="l00455"></a><span class="lineno">  455</span><span class="comment"> *     });</span></div>
<div class="line"><a id="l00456" name="l00456"></a><span class="lineno">  456</span><span class="comment"> *   }</span></div>
<div class="line"><a id="l00457" name="l00457"></a><span class="lineno">  457</span><span class="comment"> *</span></div>
<div class="line"><a id="l00458" name="l00458"></a><span class="lineno">  458</span><span class="comment"> *   void on_msg_in(const Error_code&amp; err_code, size_t sz)</span></div>
<div class="line"><a id="l00459" name="l00459"></a><span class="lineno">  459</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00460" name="l00460"></a><span class="lineno">  460</span><span class="comment"> *     // In your thread W:</span></div>
<div class="line"><a id="l00461" name="l00461"></a><span class="lineno">  461</span><span class="comment"> *     // m_my_rcv_mutex is locked!</span></div>
<div class="line"><a id="l00462" name="l00462"></a><span class="lineno">  462</span><span class="comment"> *</span></div>
<div class="line"><a id="l00463" name="l00463"></a><span class="lineno">  463</span><span class="comment"> *     ... // Handle contents of m_target_msg, or err_code indicating error.</span></div>
<div class="line"><a id="l00464" name="l00464"></a><span class="lineno">  464</span><span class="comment"> *   }</span></div>
<div class="line"><a id="l00465" name="l00465"></a><span class="lineno">  465</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00466" name="l00466"></a><span class="lineno">  466</span><span class="comment"> *</span></div>
<div class="line"><a id="l00467" name="l00467"></a><span class="lineno">  467</span><span class="comment"> * Just remember: *You* choose when `x` does anything that might touch your data, or itself.  This happens</span></div>
<div class="line"><a id="l00468" name="l00468"></a><span class="lineno">  468</span><span class="comment"> * in exactly three possible places and always synchronously:</span></div>
<div class="line"><a id="l00469" name="l00469"></a><span class="lineno">  469</span><span class="comment"> *   - The `x.async_receive_blob()` initiating call itself (and ones like it, all having async-I/O almost-identical-sig</span></div>
<div class="line"><a id="l00470" name="l00470"></a><span class="lineno">  470</span><span class="comment"> *     counterparts in `X::` for any given `sync_io::X::`).</span></div>
<div class="line"><a id="l00471" name="l00471"></a><span class="lineno">  471</span><span class="comment"> *     - OpenSSL analogy: initial `SSL_read()`.</span></div>
<div class="line"><a id="l00472" name="l00472"></a><span class="lineno">  472</span><span class="comment"> *   - Your code reacting to non-would-block return from `x.async_receive_blob()`, right after it (and ones like it).</span></div>
<div class="line"><a id="l00473" name="l00473"></a><span class="lineno">  473</span><span class="comment"> *     - OpenSSL analogy: reacting to initial `SSL_read()` succeeding right away.</span></div>
<div class="line"><a id="l00474" name="l00474"></a><span class="lineno">  474</span><span class="comment"> *   - `(*on_active_ev_func)()`.</span></div>
<div class="line"><a id="l00475" name="l00475"></a><span class="lineno">  475</span><span class="comment"> *     - OpenSSL analogy: subsequent `SSL_read()`, once you&#39;ve detected its `SSL_ERROR_WANT_*` has been satisfied.</span></div>
<div class="line"><a id="l00476" name="l00476"></a><span class="lineno">  476</span><span class="comment"> *</span></div>
<div class="line"><a id="l00477" name="l00477"></a><span class="lineno">  477</span><span class="comment"> * ### Is there always a completion handler? ###</span></div>
<div class="line"><a id="l00478" name="l00478"></a><span class="lineno">  478</span><span class="comment"> * Answer: No.  An async op might not have a completion handler, but it is still an async op and may need to</span></div>
<div class="line"><a id="l00479" name="l00479"></a><span class="lineno">  479</span><span class="comment"> * ask you to async-wait for some handle to be readable and/or writable to work properly.  The most prominent</span></div>
<div class="line"><a id="l00480" name="l00480"></a><span class="lineno">  480</span><span class="comment"> * case of this is sending items as exemplified by ipc::transport::sync_io::Native_socket_stream::send_blob().</span></div>
<div class="line"><a id="l00481" name="l00481"></a><span class="lineno">  481</span><span class="comment"> * How to handle it?  Well, it&#39;s the same as any `async_*()` op (which shall always take a completion handler) --</span></div>
<div class="line"><a id="l00482" name="l00482"></a><span class="lineno">  482</span><span class="comment"> * but simpler.  Simply put: Such an op shall be initiated by a method that takes no completion handler arg, so</span></div>
<div class="line"><a id="l00483" name="l00483"></a><span class="lineno">  483</span><span class="comment"> * you simply don&#39;t provide one.  (By convention it will also lack an `async_` prefix in the method name.)</span></div>
<div class="line"><a id="l00484" name="l00484"></a><span class="lineno">  484</span><span class="comment"> * Beyond that, everything is the same:</span></div>
<div class="line"><a id="l00485" name="l00485"></a><span class="lineno">  485</span><span class="comment"> *   - It may (or may not) initiate an async-wait by calling the `Event_wait_func` you supplied via</span></div>
<div class="line"><a id="l00486" name="l00486"></a><span class="lineno">  486</span><span class="comment"> *     `start_*ops()`.</span></div>
<div class="line"><a id="l00487" name="l00487"></a><span class="lineno">  487</span><span class="comment"> *   - Your `Event_wait_func` should indeed -- on successful async-wait -- invoke `(*on_active_ev_func)()`.</span></div>
<div class="line"><a id="l00488" name="l00488"></a><span class="lineno">  488</span><span class="comment"> *     Internally that may continue, or complete, whatever async processing `x` needs to do.</span></div>
<div class="line"><a id="l00489" name="l00489"></a><span class="lineno">  489</span><span class="comment"> *     - The difference: it won&#39;t invoke some completion handler of yours... as you didn&#39;t (and couldn&#39;t) provide one.</span></div>
<div class="line"><a id="l00490" name="l00490"></a><span class="lineno">  490</span><span class="comment"> *</span></div>
<div class="line"><a id="l00491" name="l00491"></a><span class="lineno">  491</span><span class="comment"> * ### Multiple op-types in a given `sync_io`-pattern-implementing object ###</span></div>
<div class="line"><a id="l00492" name="l00492"></a><span class="lineno">  492</span><span class="comment"> * Consider, first, ipc::session::sync_io::Session_server_adapter.  It has only one operation, really:</span></div>
<div class="line"><a id="l00493" name="l00493"></a><span class="lineno">  493</span><span class="comment"> * session::sync_io::Session_server_adapter::async_accept().  To set it up, you&#39;ll do (as explained above by another</span></div>
<div class="line"><a id="l00494" name="l00494"></a><span class="lineno">  494</span><span class="comment"> * example use case): `x.start_ops()`, possibly preceded by `x.replace_event_wait_handles()` (but that guy is</span></div>
<div class="line"><a id="l00495" name="l00495"></a><span class="lineno">  495</span><span class="comment"> * beside the point).</span></div>
<div class="line"><a id="l00496" name="l00496"></a><span class="lineno">  496</span><span class="comment"> *</span></div>
<div class="line"><a id="l00497" name="l00497"></a><span class="lineno">  497</span><span class="comment"> * Easy enough.  The `x` can&#39;t do any other &quot;type of thing.&quot;  Same is true of, say,</span></div>
<div class="line"><a id="l00498" name="l00498"></a><span class="lineno">  498</span><span class="comment"> * ipc::transport::sync_io::Blob_stream_mq_sender: it can only `x.send_blob()` (and `x.auto_ping()`,</span></div>
<div class="line"><a id="l00499" name="l00499"></a><span class="lineno">  499</span><span class="comment"> * `x.end_sending()`, `x.async_end_sending()` -- all of which deal with sending messages *out*); and needs only</span></div>
<div class="line"><a id="l00500" name="l00500"></a><span class="lineno">  500</span><span class="comment"> * `x.start_send_blob_ops()` for setup.</span></div>
<div class="line"><a id="l00501" name="l00501"></a><span class="lineno">  501</span><span class="comment"> *</span></div>
<div class="line"><a id="l00502" name="l00502"></a><span class="lineno">  502</span><span class="comment"> * What if an object can do multiple things though?  `Native_socket_stream` (operating as a `Blob_sender` and</span></div>
<div class="line"><a id="l00503" name="l00503"></a><span class="lineno">  503</span><span class="comment"> * `Blob_receiver`) can do at least 2: it can</span></div>
<div class="line"><a id="l00504" name="l00504"></a><span class="lineno">  504</span><span class="comment"> *   - send (`.send_blob()`, `.end_sending()`, `.async_end_sending()`, `.auto_ping()`),</span></div>
<div class="line"><a id="l00505" name="l00505"></a><span class="lineno">  505</span><span class="comment"> *   - and receive (`.async_receive_blob()`, `.idle_timer_run()`).</span></div>
<div class="line"><a id="l00506" name="l00506"></a><span class="lineno">  506</span><span class="comment"> *</span></div>
<div class="line"><a id="l00507" name="l00507"></a><span class="lineno">  507</span><span class="comment"> * These are 2 distinct *op-types*, and each one has its own independent API started via</span></div>
<div class="line"><a id="l00508" name="l00508"></a><span class="lineno">  508</span><span class="comment"> * `.start_send_blob_ops()` and `.start_receive_blob_ops()` respectively.  (If it were networked -- this might</span></div>
<div class="line"><a id="l00509" name="l00509"></a><span class="lineno">  509</span><span class="comment"> * be in the works -- it would probably gain a 3rd op-type via `.start_connect_ops()`.)</span></div>
<div class="line"><a id="l00510" name="l00510"></a><span class="lineno">  510</span><span class="comment"> *</span></div>
<div class="line"><a id="l00511" name="l00511"></a><span class="lineno">  511</span><span class="comment"> * Not that interesting in and of itself; but what about concurrency?  Answer:</span></div>
<div class="line"><a id="l00512" name="l00512"></a><span class="lineno">  512</span><span class="comment"> *</span></div>
<div class="line"><a id="l00513" name="l00513"></a><span class="lineno">  513</span><span class="comment"> * Things only get interesting once 2+ op-types (in practice, as of this writing, it&#39;s</span></div>
<div class="line"><a id="l00514" name="l00514"></a><span class="lineno">  514</span><span class="comment"> * 2 at most in all known use cases) can occur concurrently.  Namely that&#39;s</span></div>
<div class="line"><a id="l00515" name="l00515"></a><span class="lineno">  515</span><span class="comment"> * sending (started via `.start_send_blob_ops()` in this case) and receiving (`.start_receive_blob_ops()`).</span></div>
<div class="line"><a id="l00516" name="l00516"></a><span class="lineno">  516</span><span class="comment"> * How does it work?  Answer: Formally speaking, it&#39;s described in the appropriate class&#39;s doc header; in this case</span></div>
<div class="line"><a id="l00517" name="l00517"></a><span class="lineno">  517</span><span class="comment"> * ipc::transport::sync_io::Native_socket_stream.  Informally the intuition behind it is as follows:</span></div>
<div class="line"><a id="l00518" name="l00518"></a><span class="lineno">  518</span><span class="comment"> *   - In a full-duplex object (like this one), you can indeed send and receive at the same time.</span></div>
<div class="line"><a id="l00519" name="l00519"></a><span class="lineno">  519</span><span class="comment"> *     That is, e.g., you can interleave an async-receive-blob op and its eventual completion with</span></div>
<div class="line"><a id="l00520" name="l00520"></a><span class="lineno">  520</span><span class="comment"> *     invoking something send-related and its eventual completion (if applicable).</span></div>
<div class="line"><a id="l00521" name="l00521"></a><span class="lineno">  521</span><span class="comment"> *   - Moreover you can use the API of op-type &quot;receive&quot; *actually concurrently* with the API of op-type &quot;send.&quot;</span></div>
<div class="line"><a id="l00522" name="l00522"></a><span class="lineno">  522</span><span class="comment"> *     It *is* thread-safe, even though you&#39;re ostensily mutating the same object `x`.</span></div>
<div class="line"><a id="l00523" name="l00523"></a><span class="lineno">  523</span><span class="comment"> *     This is analogous to being able to concurrently `read(fd, ...)` and `write(fd, ...)` on the same OS handle</span></div>
<div class="line"><a id="l00524" name="l00524"></a><span class="lineno">  524</span><span class="comment"> *     `fd` for many socket types including TCP and Unix-domain-socket.  This may, all in all, lead to significant</span></div>
<div class="line"><a id="l00525" name="l00525"></a><span class="lineno">  525</span><span class="comment"> *     perf savings in your application, if you have multiple threads available to handle sending and receiving.</span></div>
<div class="line"><a id="l00526" name="l00526"></a><span class="lineno">  526</span><span class="comment"> *     If you *do* need a mutex, you can have 1 mutex for send ops and 1 mutex for receive ops (assuming of course</span></div>
<div class="line"><a id="l00527" name="l00527"></a><span class="lineno">  527</span><span class="comment"> *     your algorithm doesn&#39;t involve the 2 directions&#39; algorithms concurrently mutating the same outside-`x` data).</span></div>
<div class="line"><a id="l00528" name="l00528"></a><span class="lineno">  528</span><span class="comment"> *</span></div>
<div class="line"><a id="l00529" name="l00529"></a><span class="lineno">  529</span><span class="comment"> * Do keep in mind: This applies to `sync_io::X` only -- not its async-I/O counterpart `X`.  E.g., you cannot do</span></div>
<div class="line"><a id="l00530" name="l00530"></a><span class="lineno">  530</span><span class="comment"> * `x.async_receive_blob()` and `x.send_blob()` concurrently, in the latter case, but you can too do so in the former. </span></div>
<div class="line"><a id="l00531" name="l00531"></a><span class="lineno">  531</span><span class="comment"> * With plain `X` you&#39;d need to mutex-protect (or use strands or ...) `x`.  However you can of course still have 2+</span></div>
<div class="line"><a id="l00532" name="l00532"></a><span class="lineno">  532</span><span class="comment"> * async operations outstanding simultaneously (e.g., initiating a send while an `.async_receive_*(..., F)` has not yet</span></div>
<div class="line"><a id="l00533" name="l00533"></a><span class="lineno">  533</span><span class="comment"> * finished as signified by `F()`): you just cannot literally call mutating parts of `x` API concurrently.</span></div>
<div class="line"><a id="l00534" name="l00534"></a><span class="lineno">  534</span><span class="comment"> *</span></div>
<div class="line"><a id="l00535" name="l00535"></a><span class="lineno">  535</span><span class="comment"> * @see ipc::util::sync_io::Event_wait_func -- details about hooking up your event loop to a</span></div>
<div class="line"><a id="l00536" name="l00536"></a><span class="lineno">  536</span><span class="comment"> *      `sync_io`-pattern-implementing Flow-IPC object.</span></div>
<div class="line"><a id="l00537" name="l00537"></a><span class="lineno">  537</span><span class="comment"> * @see ipc::util::sync_io::Asio_waitable_native_handle -- take a look particularly if your event loop is built on</span></div>
<div class="line"><a id="l00538" name="l00538"></a><span class="lineno">  538</span><span class="comment"> *      boost.asio.</span></div>
<div class="line"><a id="l00539" name="l00539"></a><span class="lineno">  539</span><span class="comment"> * @see ipc::transport::Native_socket_stream internal source code: This exemplifies a fairly advanced</span></div>
<div class="line"><a id="l00540" name="l00540"></a><span class="lineno">  540</span><span class="comment"> *      &quot;eat-our-own-dog-food&quot; usage of a `sync_io`-pattern-implementing API</span></div>
<div class="line"><a id="l00541" name="l00541"></a><span class="lineno">  541</span><span class="comment"> *      (ipc::transport::sync_io::Native_socket_stream in this case) in a multi-threaded setting</span></div>
<div class="line"><a id="l00542" name="l00542"></a><span class="lineno">  542</span><span class="comment"> *      (user&#39;s thread U and internal worker thread W in this case).  In this case the event loop is a boost.asio</span></div>
<div class="line"><a id="l00543" name="l00543"></a><span class="lineno">  543</span><span class="comment"> *      one.</span></div>
<div class="line"><a id="l00544" name="l00544"></a><span class="lineno">  544</span><span class="comment"> *</span></div>
<div class="line"><a id="l00545" name="l00545"></a><span class="lineno">  545</span><span class="comment"> * @todo Write an example of `sync_io`-pattern use with an old-school reactor-pattern event loop, using</span></div>
<div class="line"><a id="l00546" name="l00546"></a><span class="lineno">  546</span><span class="comment"> *       `poll()` and/or `epoll_*()`.</span></div>
<div class="line"><a id="l00547" name="l00547"></a><span class="lineno">  547</span><span class="comment"> *</span></div>
<div class="line"><a id="l00548" name="l00548"></a><span class="lineno">  548</span><span class="comment"> * @internal</span></div>
<div class="line"><a id="l00549" name="l00549"></a><span class="lineno">  549</span><span class="comment"> *</span></div>
<div class="line"><a id="l00550" name="l00550"></a><span class="lineno">  550</span><span class="comment"> * @see ipc::util::sync_io::Timer_event_emitter -- how to hook up a boost.asio `Timer` inside</span></div>
<div class="line"><a id="l00551" name="l00551"></a><span class="lineno">  551</span><span class="comment"> *      a `sync_io`-pattern-implementing Flow-IPC object.</span></div>
<div class="line"><a id="l00552" name="l00552"></a><span class="lineno">  552</span><span class="comment"> */</span></div>
<div class="line"><a id="l00553" name="l00553"></a><span class="lineno">  553</span><span class="keyword">namespace </span><a class="code hl_namespace" href="namespaceipc_1_1util_1_1sync__io.html">ipc::util::sync_io</a></div>
<div class="line"><a id="l00554" name="l00554"></a><span class="lineno">  554</span>{</div>
<div class="line"><a id="l00555" name="l00555"></a><span class="lineno">  555</span> </div>
<div class="line"><a id="l00556" name="l00556"></a><span class="lineno">  556</span><span class="comment">// Types.</span></div>
<div class="line"><a id="l00557" name="l00557"></a><span class="lineno">  557</span> </div>
<div class="line"><a id="l00558" name="l00558"></a><span class="lineno">  558</span><span class="comment">// Find doc headers near the bodies of these compound types.</span></div>
<div class="line"><a id="l00559" name="l00559"></a><span class="lineno">  559</span> </div>
<div class="line"><a id="l00560" name="l00560"></a><span class="lineno">  560</span><span class="keyword">class </span>Asio_waitable_native_handle;</div>
<div class="line"><a id="l00561" name="l00561"></a><span class="lineno">  561</span><span class="comment"></span> </div>
<div class="line"><a id="l00562" name="l00562"></a><span class="lineno">  562</span><span class="comment">/**</span></div>
<div class="line"><a id="l00563" name="l00563"></a><span class="lineno">  563</span><span class="comment"> * Short-hand for ref-counted pointer to a `Function&lt;&gt;` that takes no arguments and returns nothing;</span></div>
<div class="line"><a id="l00564" name="l00564"></a><span class="lineno">  564</span><span class="comment"> * in particular used for `on_active_ev_func` arg of sync_io::Event_wait_func.</span></div>
<div class="line"><a id="l00565" name="l00565"></a><span class="lineno">  565</span><span class="comment"> *</span></div>
<div class="line"><a id="l00566" name="l00566"></a><span class="lineno">  566</span><span class="comment"> * ### Rationale ###</span></div>
<div class="line"><a id="l00567" name="l00567"></a><span class="lineno">  567</span><span class="comment"> * This is defined here because of its central role in sync_io::Event_wait_func (see that doc header).</span></div>
<div class="line"><a id="l00568" name="l00568"></a><span class="lineno">  568</span><span class="comment"> *</span></div>
<div class="line"><a id="l00569" name="l00569"></a><span class="lineno">  569</span><span class="comment"> * Why wrap it in a smart pointer at all as opposed to passing around `Function&lt;&gt;`s as objects (particularly</span></div>
<div class="line"><a id="l00570" name="l00570"></a><span class="lineno">  570</span><span class="comment"> * as arg to #Event_wait_func)?  Answer: Performance.  Our `sync_io` pattern is intended for the highly</span></div>
<div class="line"><a id="l00571" name="l00571"></a><span class="lineno">  571</span><span class="comment"> * perf-conscious user, to the extent they&#39;d forego the significantly easier to use async-I/O pattern</span></div>
<div class="line"><a id="l00572" name="l00572"></a><span class="lineno">  572</span><span class="comment"> * just because that would involve involuntary (from the user&#39;s point of view) thread creation and context</span></div>
<div class="line"><a id="l00573" name="l00573"></a><span class="lineno">  573</span><span class="comment"> * switching; copying or moving polymorphic functors, including all their captures, is an unnecessary expense.</span></div>
<div class="line"><a id="l00574" name="l00574"></a><span class="lineno">  574</span><span class="comment"> *</span></div>
<div class="line"><a id="l00575" name="l00575"></a><span class="lineno">  575</span><span class="comment"> * In that case why `shared_ptr`, not `unique_ptr`, given that it adds potential ref-counting behind the scenes?</span></div>
<div class="line"><a id="l00576" name="l00576"></a><span class="lineno">  576</span><span class="comment"> * Answer: `unique_ptr` would have been nice; however it is likely the user (and/or internal Flow-IPC code)</span></div>
<div class="line"><a id="l00577" name="l00577"></a><span class="lineno">  577</span><span class="comment"> * will want to lambda-capture the wrapped `Task`, and capturing movable-but-not-copyable types like `unique_ptr`</span></div>
<div class="line"><a id="l00578" name="l00578"></a><span class="lineno">  578</span><span class="comment"> * does not compile (as of C++17), even if one never copies the capturing lambda.  One would need to upgrade</span></div>
<div class="line"><a id="l00579" name="l00579"></a><span class="lineno">  579</span><span class="comment"> * to `shared_ptr` to capture, and that is annoying.</span></div>
<div class="line"><a id="l00580" name="l00580"></a><span class="lineno">  580</span><span class="comment"> *</span></div>
<div class="line"><a id="l00581" name="l00581"></a><span class="lineno">  581</span><span class="comment"> * @note That said it is recommended that one `std::move()` any #Task_ptr whenever possible, such as when</span></div>
<div class="line"><a id="l00582" name="l00582"></a><span class="lineno">  582</span><span class="comment"> *       capturing it in a lambda (e.g., `[task_ptr = std::move(task_ptr)`).  This advice applies generally</span></div>
<div class="line"><a id="l00583" name="l00583"></a><span class="lineno">  583</span><span class="comment"> *       to all `shared_ptr` captures (*&quot;whenever possible&quot;* being important), but this is just a reminder.</span></div>
<div class="line"><a id="l00584" name="l00584"></a><span class="lineno">  584</span><span class="comment"> */</span></div>
<div class="line"><a id="l00585" name="l00585"></a><span class="lineno"><a class="line" href="namespaceipc_1_1util_1_1sync__io.html#ac6973c71fc70c6d867b0f2255c642532">  585</a></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc_1_1util_1_1sync__io.html#ac6973c71fc70c6d867b0f2255c642532">Task_ptr</a> = boost::shared_ptr&lt;Task&gt;;</div>
<div class="line"><a id="l00586" name="l00586"></a><span class="lineno">  586</span><span class="comment"></span> </div>
<div class="line"><a id="l00587" name="l00587"></a><span class="lineno">  587</span><span class="comment">/**</span></div>
<div class="line"><a id="l00588" name="l00588"></a><span class="lineno">  588</span><span class="comment"> * In `sync_io` pattern, concrete type storing user-supplied function invoked by pattern-implementing</span></div>
<div class="line"><a id="l00589" name="l00589"></a><span class="lineno">  589</span><span class="comment"> * ipc::transport and ipc::session object to indicate interest in an I/O status event (writable, readable)</span></div>
<div class="line"><a id="l00590" name="l00590"></a><span class="lineno">  590</span><span class="comment"> * for a particular Native_handle.</span></div>
<div class="line"><a id="l00591" name="l00591"></a><span class="lineno">  591</span><span class="comment"> *</span></div>
<div class="line"><a id="l00592" name="l00592"></a><span class="lineno">  592</span><span class="comment"> * @see ipc::util::sync_io doc header first.  It explains the pattern in detail including example code for</span></div>
<div class="line"><a id="l00593" name="l00593"></a><span class="lineno">  593</span><span class="comment"> *      setting up an `Event_wait_func`.</span></div>
<div class="line"><a id="l00594" name="l00594"></a><span class="lineno">  594</span><span class="comment"> *</span></div>
<div class="line"><a id="l00595" name="l00595"></a><span class="lineno">  595</span><span class="comment"> * Use in `sync_io` pattern</span></div>
<div class="line"><a id="l00596" name="l00596"></a><span class="lineno">  596</span><span class="comment"> * ------------------------</span></div>
<div class="line"><a id="l00597" name="l00597"></a><span class="lineno">  597</span><span class="comment"> * Suppose `T` is an ipc::transport or ipc::session object type, always in a `&quot;sync_io&quot;` sub-namespace, that</span></div>
<div class="line"><a id="l00598" name="l00598"></a><span class="lineno">  598</span><span class="comment"> * operates according to the `sync_io` pattern.  (For example, `T` might be transport::sync_io::Native_socket_stream.)</span></div>
<div class="line"><a id="l00599" name="l00599"></a><span class="lineno">  599</span><span class="comment"> * Then `T::start_*ops(Event_wait_func&amp;&amp;)`, and/or a compatible template, must be invoked to begin unidirectional work</span></div>
<div class="line"><a id="l00600" name="l00600"></a><span class="lineno">  600</span><span class="comment"> * of type X (e.g., `start_*ops()` might be `start_send_blob_ops()` or</span></div>
<div class="line"><a id="l00601" name="l00601"></a><span class="lineno">  601</span><span class="comment"> * `start_receive_native_handle_ops()`) on a given `T`; the `T` memorizes the function until its destruction.</span></div>
<div class="line"><a id="l00602" name="l00602"></a><span class="lineno">  602</span><span class="comment"> *</span></div>
<div class="line"><a id="l00603" name="l00603"></a><span class="lineno">  603</span><span class="comment"> * From that point on, the `T` might at times be unable to complete an operation (for example</span></div>
<div class="line"><a id="l00604" name="l00604"></a><span class="lineno">  604</span><span class="comment"> * transport::sync_io::Native_socket_stream::send_blob()) synchronously due to a would-block condition on some</span></div>
<div class="line"><a id="l00605" name="l00605"></a><span class="lineno">  605</span><span class="comment"> * internal Native_handle (for example, internally, the Unix domain stream socket in this case encountering</span></div>
<div class="line"><a id="l00606" name="l00606"></a><span class="lineno">  606</span><span class="comment"> * would-block on a `&quot;::writemsg()&quot;` attempt).  It shall then -- synchronously, inside</span></div>
<div class="line"><a id="l00607" name="l00607"></a><span class="lineno">  607</span><span class="comment"> * `Native_socket_stream::send_blob()` -- invoke the saved #Event_wait_func and pass to it the following arguments:</span></div>
<div class="line"><a id="l00608" name="l00608"></a><span class="lineno">  608</span><span class="comment"> *   - `hndl_of_interest`: The native handle on which the user&#39;s own event loop must wait for an I/O event.</span></div>
<div class="line"><a id="l00609" name="l00609"></a><span class="lineno">  609</span><span class="comment"> *      In-depth tips on how to do so are below; but for now:</span></div>
<div class="line"><a id="l00610" name="l00610"></a><span class="lineno">  610</span><span class="comment"> *      - If your event loop is built on boost.asio, you may use `hndl_of_interest-&gt;async_wait()` directly.</span></div>
<div class="line"><a id="l00611" name="l00611"></a><span class="lineno">  611</span><span class="comment"> *      - Otherwise (if you&#39;re using `[e]poll*()` perhaps), obtain the raw handle as follows:</span></div>
<div class="line"><a id="l00612" name="l00612"></a><span class="lineno">  612</span><span class="comment"> *        `hndl_of_interest-&gt;native_handle().m_native_handle`.  It can be input to `poll()`, `epoll_ctl()`, etc.</span></div>
<div class="line"><a id="l00613" name="l00613"></a><span class="lineno">  613</span><span class="comment"> *   - `ev_of_interest_snd_else_rcv`: Which event it must await: `true` means &quot;writable&quot;; `false` means &quot;readable.&quot;</span></div>
<div class="line"><a id="l00614" name="l00614"></a><span class="lineno">  614</span><span class="comment"> *     - What if the user&#39;s wait (such as `epoll_wait()`) encounters an error-occurred event instead</span></div>
<div class="line"><a id="l00615" name="l00615"></a><span class="lineno">  615</span><span class="comment"> *       (`EPOLLERR`)?</span></div>
<div class="line"><a id="l00616" name="l00616"></a><span class="lineno">  616</span><span class="comment"> *       Answer: They must in fact report this as-if the requested event (whether writable or readable) is active.</span></div>
<div class="line"><a id="l00617" name="l00617"></a><span class="lineno">  617</span><span class="comment"> *   - `on_active_ev_func`: If (and, to avoid pointless perf loss, only if) the above-specified event is active,</span></div>
<div class="line"><a id="l00618" name="l00618"></a><span class="lineno">  618</span><span class="comment"> *     the user must invoke `(*on_active_ev_func)()` (without args and expecting no return value).</span></div>
<div class="line"><a id="l00619" name="l00619"></a><span class="lineno">  619</span><span class="comment"> *     - In terms of thread safety, and generally, one should consider this function a non-`const` member of `T`&#39;s</span></div>
<div class="line"><a id="l00620" name="l00620"></a><span class="lineno">  620</span><span class="comment"> *       sub-API.  (The sub-API in question is the set of methods that correspond to unidirectional-operation</span></div>
<div class="line"><a id="l00621" name="l00621"></a><span class="lineno">  621</span><span class="comment"> *       of type X, where `T::start_*ops()` was invoked to kick things off.  For example, in `Native_socket_stream`</span></div>
<div class="line"><a id="l00622" name="l00622"></a><span class="lineno">  622</span><span class="comment"> *       as used as a Blob_sender, that&#39;s its `send_blob()` and `*end_sending()` methods.)</span></div>
<div class="line"><a id="l00623" name="l00623"></a><span class="lineno">  623</span><span class="comment"> *       That is, `(*on_active_ev_func)()` may not be called concurrently to any `T` sub-API method</span></div>
<div class="line"><a id="l00624" name="l00624"></a><span class="lineno">  624</span><span class="comment"> *       (`Native_socket_stream::send_blob()`, `*end_sending()` in the recent example) or other</span></div>
<div class="line"><a id="l00625" name="l00625"></a><span class="lineno">  625</span><span class="comment"> *       `(*on_active_ev_func)()`.  `(*on_active_ev_func)()` may well, itself, synchronously invoke</span></div>
<div class="line"><a id="l00626" name="l00626"></a><span class="lineno">  626</span><span class="comment"> *       `Event_wait_func` to indicate interest in a new event.</span></div>
<div class="line"><a id="l00627" name="l00627"></a><span class="lineno">  627</span><span class="comment"> *</span></div>
<div class="line"><a id="l00628" name="l00628"></a><span class="lineno">  628</span><span class="comment"> * Naturally the key question arises: what, specifically, should a particular #Event_wait_func (as passed-into</span></div>
<div class="line"><a id="l00629" name="l00629"></a><span class="lineno">  629</span><span class="comment"> * a `T::start_*ops()`) *do*?  Indeed, this requires great care on the `sync_io` pattern user&#39;s part.</span></div>
<div class="line"><a id="l00630" name="l00630"></a><span class="lineno">  630</span><span class="comment"> *</span></div>
<div class="line"><a id="l00631" name="l00631"></a><span class="lineno">  631</span><span class="comment"> * Formally speaking the contract is as follows.  Let `F` be the particular `Event_wait_func`.</span></div>
<div class="line"><a id="l00632" name="l00632"></a><span class="lineno">  632</span><span class="comment"> *   -# Upon `F()` being called, it shall register -- through a technique of the user&#39;s choice (a couple are</span></div>
<div class="line"><a id="l00633" name="l00633"></a><span class="lineno">  633</span><span class="comment"> *      explained below for your convenience) -- the specified event as one of interest.  The sooner this registration</span></div>
<div class="line"><a id="l00634" name="l00634"></a><span class="lineno">  634</span><span class="comment"> *      occurs, the more responsively `T` will behave.</span></div>
<div class="line"><a id="l00635" name="l00635"></a><span class="lineno">  635</span><span class="comment"> *   -# It shall arrange, via that same technique, to do the following upon detecting the</span></div>
<div class="line"><a id="l00636" name="l00636"></a><span class="lineno">  636</span><span class="comment"> *      event (or `hndl_of_interest` becoming hosed, i.e., the error event).  The sooner it does so, the more</span></div>
<div class="line"><a id="l00637" name="l00637"></a><span class="lineno">  637</span><span class="comment"> *      responsively `T` will behave.</span></div>
<div class="line"><a id="l00638" name="l00638"></a><span class="lineno">  638</span><span class="comment"> *      -# *Deregister* the specified event.  Each `Event_wait_func` invocation indicates a **one-off** wait.</span></div>
<div class="line"><a id="l00639" name="l00639"></a><span class="lineno">  639</span><span class="comment"> *      -# Call `(*on_active_ev_func)()`.  (It is best, for a little perf bump, for the user</span></div>
<div class="line"><a id="l00640" name="l00640"></a><span class="lineno">  640</span><span class="comment"> *         to save `std::move(on_active_ev_func))` as opposed to a smart-pointer copy.)</span></div>
<div class="line"><a id="l00641" name="l00641"></a><span class="lineno">  641</span><span class="comment"> *</span></div>
<div class="line"><a id="l00642" name="l00642"></a><span class="lineno">  642</span><span class="comment"> * @warning Do not forget to deregister the event before `(*on_active_ev_func)()`.  Failure to do so can easily</span></div>
<div class="line"><a id="l00643" name="l00643"></a><span class="lineno">  643</span><span class="comment"> *          result in processor pegging at best; or undefined behavior/assertion tripping.</span></div>
<div class="line"><a id="l00644" name="l00644"></a><span class="lineno">  644</span><span class="comment"> *          Worse still, if it&#39;s mere processor pegging, you might not notice it happening.</span></div>
<div class="line"><a id="l00645" name="l00645"></a><span class="lineno">  645</span><span class="comment"> *          E.g., if `Native_socket_stream::send*()` encounters would-block internally,</span></div>
<div class="line"><a id="l00646" name="l00646"></a><span class="lineno">  646</span><span class="comment"> *          it will register interest in writability of an internal handle; suppose when you report writability</span></div>
<div class="line"><a id="l00647" name="l00647"></a><span class="lineno">  647</span><span class="comment"> *          it is able to push-through any queued internal payload.  Now it no longer needs writability; if</span></div>
<div class="line"><a id="l00648" name="l00648"></a><span class="lineno">  648</span><span class="comment"> *          informed of writability anyway, it will at best do nothing -- leading to an infinite loop</span></div>
<div class="line"><a id="l00649" name="l00649"></a><span class="lineno">  649</span><span class="comment"> *          of user reporting writability and `Native_socket_stream` ignoring it.  Or, if that is how</span></div>
<div class="line"><a id="l00650" name="l00650"></a><span class="lineno">  650</span><span class="comment"> *          `Native_socket_stream` is written, it will detect that a write event is being reported despite it</span></div>
<div class="line"><a id="l00651" name="l00651"></a><span class="lineno">  651</span><span class="comment"> *          not asking for this and log WARNING or even FATAL/abort program.  With `epoll_*()`, `EPOLLONESHOT` and/or</span></div>
<div class="line"><a id="l00652" name="l00652"></a><span class="lineno">  652</span><span class="comment"> *          `EPOLLET` may be of aid, but be very careful.</span></div>
<div class="line"><a id="l00653" name="l00653"></a><span class="lineno">  653</span><span class="comment"> *</span></div>
<div class="line"><a id="l00654" name="l00654"></a><span class="lineno">  654</span><span class="comment"> * ### Integrating with reactor-pattern `poll()` and similar ###</span></div>
<div class="line"><a id="l00655" name="l00655"></a><span class="lineno">  655</span><span class="comment"> * Suppose your application is using POSIX `poll()`.  Typically a data structure will be maintained mirroring</span></div>
<div class="line"><a id="l00656" name="l00656"></a><span class="lineno">  656</span><span class="comment"> * the `fds[].events` (events of interest) sub-argument to `poll()`; for example an `unordered_map&lt;&gt;` from FD</span></div>
<div class="line"><a id="l00657" name="l00657"></a><span class="lineno">  657</span><span class="comment"> * (Native_handle::m_native_handle) to an `enum { S_NONE, S_RD, S_WR, S_RD_WR }`; or simply the `fds[]` array itself.</span></div>
<div class="line"><a id="l00658" name="l00658"></a><span class="lineno">  658</span><span class="comment"> * (In the latter case lookup by FD may not be constant-time.  However `fds[].events` does not need to be built</span></div>
<div class="line"><a id="l00659" name="l00659"></a><span class="lineno">  659</span><span class="comment"> * from a mirroring structure ahead of each `poll()`.)</span></div>
<div class="line"><a id="l00660" name="l00660"></a><span class="lineno">  660</span><span class="comment"> *</span></div>
<div class="line"><a id="l00661" name="l00661"></a><span class="lineno">  661</span><span class="comment"> * When `Event_wait_func F(hndl, snd_else_rcv, on_ev_func)` is invoked, you will register the event:</span></div>
<div class="line"><a id="l00662" name="l00662"></a><span class="lineno">  662</span><span class="comment"> *   -# If necessary, insert `raw_hndl = hndl-&gt;native_handle().m_native_handle` into the data structure,</span></div>
<div class="line"><a id="l00663" name="l00663"></a><span class="lineno">  663</span><span class="comment"> *      with no events of interest (which will change in the next step).</span></div>
<div class="line"><a id="l00664" name="l00664"></a><span class="lineno">  664</span><span class="comment"> *      If not necessary (already inserted, hence with a (different) event of interest already), continue to next step.</span></div>
<div class="line"><a id="l00665" name="l00665"></a><span class="lineno">  665</span><span class="comment"> *   -# Depending on `snd_else_rcv`, change the events-of-interest `enum` NONE-&gt;RD, NONE-&gt;WR, WR-&gt;RD_WR, or</span></div>
<div class="line"><a id="l00666" name="l00666"></a><span class="lineno">  666</span><span class="comment"> *      RD-&gt;RD_WR.  (If operating on an `fd[].events` directly, that&#39;s: `fd.events = fd.events | POLLIN` or</span></div>
<div class="line"><a id="l00667" name="l00667"></a><span class="lineno">  667</span><span class="comment"> *      `fd.events = fd.events | POLLOUT`.)</span></div>
<div class="line"><a id="l00668" name="l00668"></a><span class="lineno">  668</span><span class="comment"> *   -# In some data structure keyed on, conceptually, the pair `(raw_hndl, bool snd_else_rcv)`,</span></div>
<div class="line"><a id="l00669" name="l00669"></a><span class="lineno">  669</span><span class="comment"> *      record `std::move(on_ev_func)`.  Call it, say, `ipc_events_map`.</span></div>
<div class="line"><a id="l00670" name="l00670"></a><span class="lineno">  670</span><span class="comment"> *</span></div>
<div class="line"><a id="l00671" name="l00671"></a><span class="lineno">  671</span><span class="comment"> * At some point in your reactor-pattern event loop, you are ready to call `poll()`.  Construct `fds[].events` array</span></div>
<div class="line"><a id="l00672" name="l00672"></a><span class="lineno">  672</span><span class="comment"> * if needed, or just use the long-term-maintained one, depending on how you&#39;ve set this up.  Call `poll()`.</span></div>
<div class="line"><a id="l00673" name="l00673"></a><span class="lineno">  673</span><span class="comment"> * For each *individual* active event in an `fds[].revents`:</span></div>
<div class="line"><a id="l00674" name="l00674"></a><span class="lineno">  674</span><span class="comment"> *   -# Construct the pair `(raw_hndl, snd_else_rcv)`.</span></div>
<div class="line"><a id="l00675" name="l00675"></a><span class="lineno">  675</span><span class="comment"> *   -# If it&#39;s not in `ipc_events_map`, no IPC-relevant event fired; it must be something relevant to other</span></div>
<div class="line"><a id="l00676" name="l00676"></a><span class="lineno">  676</span><span class="comment"> *      parts of your application (such as network traffic).  Exit algorithm for now (until next `poll()`);</span></div>
<div class="line"><a id="l00677" name="l00677"></a><span class="lineno">  677</span><span class="comment"> *      the IPC-registered event is still being waited-on.</span></div>
<div class="line"><a id="l00678" name="l00678"></a><span class="lineno">  678</span><span class="comment"> *   -# If it *is* in `ipc_events_map`:</span></div>
<div class="line"><a id="l00679" name="l00679"></a><span class="lineno">  679</span><span class="comment"> *      -# Remove it from there.</span></div>
<div class="line"><a id="l00680" name="l00680"></a><span class="lineno">  680</span><span class="comment"> *      -# Deregister the event w/r/t next `poll()`:</span></div>
<div class="line"><a id="l00681" name="l00681"></a><span class="lineno">  681</span><span class="comment"> *         -# Depending on `snd_else_rcv`: Change the events-of-interest `enum` RD-&gt;NONE, WR-&gt;NONE, RD_WR-&gt;WR, or</span></div>
<div class="line"><a id="l00682" name="l00682"></a><span class="lineno">  682</span><span class="comment"> *            RD_WR-&gt;RD.  (If operating on an `fd[].events` directly, that&#39;s `fd.events = fd.events &amp; ~POLLIN)` or</span></div>
<div class="line"><a id="l00683" name="l00683"></a><span class="lineno">  683</span><span class="comment"> *            `fd.events = fd.events &amp; ~POLLOUT`.)</span></div>
<div class="line"><a id="l00684" name="l00684"></a><span class="lineno">  684</span><span class="comment"> *         -# If the events-of-interest for the FD have become NONE (or `fd.events == 0` if tracking it directly),</span></div>
<div class="line"><a id="l00685" name="l00685"></a><span class="lineno">  685</span><span class="comment"> *            delete the handle&#39;s entry from the `events`-mirroring structure (or `events` itself if tracking it</span></div>
<div class="line"><a id="l00686" name="l00686"></a><span class="lineno">  686</span><span class="comment"> *            directly).</span></div>
<div class="line"><a id="l00687" name="l00687"></a><span class="lineno">  687</span><span class="comment"> *      -# Invoke the saved `(*on_ev_func)()`.</span></div>
<div class="line"><a id="l00688" name="l00688"></a><span class="lineno">  688</span><span class="comment"> *</span></div>
<div class="line"><a id="l00689" name="l00689"></a><span class="lineno">  689</span><span class="comment"> * @note While each `F()` invocation indicates one-off event interest, the handler `(*on_ev_func)()` will sometimes,</span></div>
<div class="line"><a id="l00690" name="l00690"></a><span class="lineno">  690</span><span class="comment"> *       or possibly frequently, re-indicate interest in the same event within its own handler.  If done very</span></div>
<div class="line"><a id="l00691" name="l00691"></a><span class="lineno">  691</span><span class="comment"> *       carefully, it *might* be possible to detect this situation by deferring the editing of `events` or</span></div>
<div class="line"><a id="l00692" name="l00692"></a><span class="lineno">  692</span><span class="comment"> *       the mirroring structure until `(*on_ev_func)()` finishes; possibly this would net to making no change to</span></div>
<div class="line"><a id="l00693" name="l00693"></a><span class="lineno">  693</span><span class="comment"> *       the events-of-interest structure.  This could save some processor cycles.  I (ygoldfel) would recommend</span></div>
<div class="line"><a id="l00694" name="l00694"></a><span class="lineno">  694</span><span class="comment"> *       only getting into that if compelling perf savings evidence appears.</span></div>
<div class="line"><a id="l00695" name="l00695"></a><span class="lineno">  695</span><span class="comment"> *</span></div>
<div class="line"><a id="l00696" name="l00696"></a><span class="lineno">  696</span><span class="comment"> * @note You might notice `hndl` is a pointer to Asio_waitable_native_handle, but you simply get `raw_hndl`</span></div>
<div class="line"><a id="l00697" name="l00697"></a><span class="lineno">  697</span><span class="comment"> *       out of it and forget about the rest of `*hndl`.  Why not just provide `raw_hndl` to you?  Answer:</span></div>
<div class="line"><a id="l00698" name="l00698"></a><span class="lineno">  698</span><span class="comment"> *       It is useful when *not* integrating with a reactor-pattern event loop a-la `poll()` or similar but</span></div>
<div class="line"><a id="l00699" name="l00699"></a><span class="lineno">  699</span><span class="comment"> *       rather when integrating with a boost.asio event loop.  See &quot;Integrating with boost.asio&quot; below.</span></div>
<div class="line"><a id="l00700" name="l00700"></a><span class="lineno">  700</span><span class="comment"> *</span></div>
<div class="line"><a id="l00701" name="l00701"></a><span class="lineno">  701</span><span class="comment"> * ### What about `epoll_*()`? ###</span></div>
<div class="line"><a id="l00702" name="l00702"></a><span class="lineno">  702</span><span class="comment"> * In Linux `epoll_*()` is considered superior (its `man` page at least says that, when used in non-`EPOLLET`</span></div>
<div class="line"><a id="l00703" name="l00703"></a><span class="lineno">  703</span><span class="comment"> * mode, it is a &quot;faster&quot; `poll()`).  We leave the exercise of how to apply the above suggestions (for `poll()`)</span></div>
<div class="line"><a id="l00704" name="l00704"></a><span class="lineno">  704</span><span class="comment"> * to `epoll_*()` to the reader.  Briefly: Essentially `epoll_ctl()` lets the kernel track a long-running `fds[].events`</span></div>
<div class="line"><a id="l00705" name="l00705"></a><span class="lineno">  705</span><span class="comment"> * sub-array, with add/remove/modify operations specified by the user as syscalls.  However, it&#39;s not possible to simply</span></div>
<div class="line"><a id="l00706" name="l00706"></a><span class="lineno">  706</span><span class="comment"> * say &quot;I am interested in FD X, event writable&quot;; the events-of-interest per FD are still specified as</span></div>
<div class="line"><a id="l00707" name="l00707"></a><span class="lineno">  707</span><span class="comment"> * an ORing of `EPOLLIN` and/or `EPOLLOUT` in one per-FD entry, whereas `Event_wait_func` is finer-grained than that.</span></div>
<div class="line"><a id="l00708" name="l00708"></a><span class="lineno">  708</span><span class="comment"> * It is not possible to iterate through the kernel-stored events-of-interest set or obtain the existing</span></div>
<div class="line"><a id="l00709" name="l00709"></a><span class="lineno">  709</span><span class="comment"> * `events` bit-mask so as to then `|=` or `&amp;=` it.  Therefore a mirroring data structure (such as the</span></div>
<div class="line"><a id="l00710" name="l00710"></a><span class="lineno">  710</span><span class="comment"> * aforementioned `unordered_map&lt;&gt;` from FD to rd/wr/rd-wr) may be necessary in practice.  In my (ygoldfel)</span></div>
<div class="line"><a id="l00711" name="l00711"></a><span class="lineno">  711</span><span class="comment"> * experience using such a mirroring thing is typical in any case.</span></div>
<div class="line"><a id="l00712" name="l00712"></a><span class="lineno">  712</span><span class="comment"> *</span></div>
<div class="line"><a id="l00713" name="l00713"></a><span class="lineno">  713</span><span class="comment"> * One tip: `EPOLLONESHOT` may be quite useful: It means you can limit your code to just doing</span></div>
<div class="line"><a id="l00714" name="l00714"></a><span class="lineno">  714</span><span class="comment"> * `epoll_ctl(...ADD)` without requiring the counterpart `epoll_ctl(...DEL)` once the event does fire.</span></div>
<div class="line"><a id="l00715" name="l00715"></a><span class="lineno">  715</span><span class="comment"> * (`EPOLLET` may be usable to decrease the number of epoll-ctl calls needed further, but as of this writing</span></div>
<div class="line"><a id="l00716" name="l00716"></a><span class="lineno">  716</span><span class="comment"> * we haven&#39;t investigated this sufficiently to make a statement.)</span></div>
<div class="line"><a id="l00717" name="l00717"></a><span class="lineno">  717</span><span class="comment"> *</span></div>
<div class="line"><a id="l00718" name="l00718"></a><span class="lineno">  718</span><span class="comment"> * However `EPOLLONESHOT` pertains to the entire descriptor, not one specific waited-on event (read or write).</span></div>
<div class="line"><a id="l00719" name="l00719"></a><span class="lineno">  719</span><span class="comment"> * Therefore this optimization is helpful only if `.events` is being set to `EPOLLIN` or `EPOLLOUT` -- not</span></div>
<div class="line"><a id="l00720" name="l00720"></a><span class="lineno">  720</span><span class="comment"> * `EPOLLIN | EPOLLOUT`.  Be careful.</span></div>
<div class="line"><a id="l00721" name="l00721"></a><span class="lineno">  721</span><span class="comment"> *</span></div>
<div class="line"><a id="l00722" name="l00722"></a><span class="lineno">  722</span><span class="comment"> * ### Integrating with boost.asio ###</span></div>
<div class="line"><a id="l00723" name="l00723"></a><span class="lineno">  723</span><span class="comment"> * Suppose your application is using boost.asio (possibly with flow.async to manage threads),</span></div>
<div class="line"><a id="l00724" name="l00724"></a><span class="lineno">  724</span><span class="comment"> * with a `flow::util::Task_engine::run()` comprising the event loop, in proactor pattern fashion.</span></div>
<div class="line"><a id="l00725" name="l00725"></a><span class="lineno">  725</span><span class="comment"> * (We would recommend just that, preferring it to an old-school reactor-pattern via `[e]poll*()` directly.)</span></div>
<div class="line"><a id="l00726" name="l00726"></a><span class="lineno">  726</span><span class="comment"> * *Your* loop is asynchronously expressed, but you can still use the `sync_io` pattern to graft</span></div>
<div class="line"><a id="l00727" name="l00727"></a><span class="lineno">  727</span><span class="comment"> * Flow-IPC operations into it, so that they are invoked synchronously, when you want, in the exact thread you</span></div>
<div class="line"><a id="l00728" name="l00728"></a><span class="lineno">  728</span><span class="comment"> * want.  In fact, doing so is *significantly* simpler than integrating with a reactor-style `[e]poll*()`.</span></div>
<div class="line"><a id="l00729" name="l00729"></a><span class="lineno">  729</span><span class="comment"> * That is because, conceptually, each `Event_wait_func` invocation is essentially expressing the following</span></div>
<div class="line"><a id="l00730" name="l00730"></a><span class="lineno">  730</span><span class="comment"> * boost.asio operation:</span></div>
<div class="line"><a id="l00731" name="l00731"></a><span class="lineno">  731</span><span class="comment"> *</span></div>
<div class="line"><a id="l00732" name="l00732"></a><span class="lineno">  732</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00733" name="l00733"></a><span class="lineno">  733</span><span class="comment"> *   some_low_level_transport.async_wait(wait_write, // (or `wait_read`.)</span></div>
<div class="line"><a id="l00734" name="l00734"></a><span class="lineno">  734</span><span class="comment"> *                                       [...](const Error_code&amp; err_code)</span></div>
<div class="line"><a id="l00735" name="l00735"></a><span class="lineno">  735</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00736" name="l00736"></a><span class="lineno">  736</span><span class="comment"> *     // Can do I/O, or error?  Do I/O, or handle error.</span></div>
<div class="line"><a id="l00737" name="l00737"></a><span class="lineno">  737</span><span class="comment"> *     // ...If no error then possibly even at some point continue the async-op chain...</span></div>
<div class="line"><a id="l00738" name="l00738"></a><span class="lineno">  738</span><span class="comment"> *     same_or_other_low_level_transport.async_wait(wait_write, // (or `wait_read`.)</span></div>
<div class="line"><a id="l00739" name="l00739"></a><span class="lineno">  739</span><span class="comment"> *                                                  ...);</span></div>
<div class="line"><a id="l00740" name="l00740"></a><span class="lineno">  740</span><span class="comment"> *   }</span></div>
<div class="line"><a id="l00741" name="l00741"></a><span class="lineno">  741</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00742" name="l00742"></a><span class="lineno">  742</span><span class="comment"> *</span></div>
<div class="line"><a id="l00743" name="l00743"></a><span class="lineno">  743</span><span class="comment"> * Because of that you have to code essentially none of the stuff above (pertaining to a reactor-style `[e]poll*()`</span></div>
<div class="line"><a id="l00744" name="l00744"></a><span class="lineno">  744</span><span class="comment"> * loop): no manual registering/deregistering, wondering how to handle error-event, etc. etc.</span></div>
<div class="line"><a id="l00745" name="l00745"></a><span class="lineno">  745</span><span class="comment"> *</span></div>
<div class="line"><a id="l00746" name="l00746"></a><span class="lineno">  746</span><span class="comment"> * So what to do, specifically?  It is quite straightforward.  Suppose you&#39;re got `Task_engine E` doing</span></div>
<div class="line"><a id="l00747" name="l00747"></a><span class="lineno">  747</span><span class="comment"> * `E.run()` as your event loop.  (Any `flow::async::*_loop` does that too, just internally once you do</span></div>
<div class="line"><a id="l00748" name="l00748"></a><span class="lineno">  748</span><span class="comment"> * `loop.start()`.)  E.g., if you&#39;ve got TCP sockets attached to `E`, you might be doing</span></div>
<div class="line"><a id="l00749" name="l00749"></a><span class="lineno">  749</span><span class="comment"> * `m_tcp_sock.async_read_some(..., [](const Error_code&amp; err_code) { ... };` and so on.</span></div>
<div class="line"><a id="l00750" name="l00750"></a><span class="lineno">  750</span><span class="comment"> *</span></div>
<div class="line"><a id="l00751" name="l00751"></a><span class="lineno">  751</span><span class="comment"> * When `Event_wait_func F(hndl, snd_else_rcv, on_ev_func)` is invoked, you will simply do:</span></div>
<div class="line"><a id="l00752" name="l00752"></a><span class="lineno">  752</span><span class="comment"> *</span></div>
<div class="line"><a id="l00753" name="l00753"></a><span class="lineno">  753</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00754" name="l00754"></a><span class="lineno">  754</span><span class="comment"> *   hndl-&gt;async_wait(snd_else_rcv ? Asio_waitable_native_handle::Base::wait_write</span></div>
<div class="line"><a id="l00755" name="l00755"></a><span class="lineno">  755</span><span class="comment"> *                                 : Asio_waitable_native_handle::Base::wait_read,</span></div>
<div class="line"><a id="l00756" name="l00756"></a><span class="lineno">  756</span><span class="comment"> *                    [on_ev_func = std::move(on_ev_func)](const Error_code&amp; err_code)</span></div>
<div class="line"><a id="l00757" name="l00757"></a><span class="lineno">  757</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00758" name="l00758"></a><span class="lineno">  758</span><span class="comment"> *     if (err_code != boost::asio::error::operation_aborted)</span></div>
<div class="line"><a id="l00759" name="l00759"></a><span class="lineno">  759</span><span class="comment"> *     {</span></div>
<div class="line"><a id="l00760" name="l00760"></a><span class="lineno">  760</span><span class="comment"> *       (*on_ev_func)(); // Note: err_code is disregarded.  Whether it&#39;s readable/writable or hosed, must invoke.</span></div>
<div class="line"><a id="l00761" name="l00761"></a><span class="lineno">  761</span><span class="comment"> *     }</span></div>
<div class="line"><a id="l00762" name="l00762"></a><span class="lineno">  762</span><span class="comment"> *     // else { Stuff is shutting down; do absolutely nothing!  SOP on operation_aborted generally. }</span></div>
<div class="line"><a id="l00763" name="l00763"></a><span class="lineno">  763</span><span class="comment"> *   }</span></div>
<div class="line"><a id="l00764" name="l00764"></a><span class="lineno">  764</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00765" name="l00765"></a><span class="lineno">  765</span><span class="comment"> *</span></div>
<div class="line"><a id="l00766" name="l00766"></a><span class="lineno">  766</span><span class="comment"> * Basically, Flow-IPC wants to do an `async_wait()`... so you do it for Flow-IPC, being the master of your</span></div>
<div class="line"><a id="l00767" name="l00767"></a><span class="lineno">  767</span><span class="comment"> * (boost.asio) domain (so to speak).</span></div>
<div class="line"><a id="l00768" name="l00768"></a><span class="lineno">  768</span><span class="comment"> *</span></div>
<div class="line"><a id="l00769" name="l00769"></a><span class="lineno">  769</span><span class="comment"> * `hndl` is an `Asio_waitable_native_handle*`.  Asio_waitable_native_handle is a razor-thin wrapper around</span></div>
<div class="line"><a id="l00770" name="l00770"></a><span class="lineno">  770</span><span class="comment"> * a boost.asio `posix::descriptor` which itself is a thin wrapper around a native handle (FD).  It has</span></div>
<div class="line"><a id="l00771" name="l00771"></a><span class="lineno">  771</span><span class="comment"> * boost.asio-supplied `.async_wait()`.  However, and this is a key point:</span></div>
<div class="line"><a id="l00772" name="l00772"></a><span class="lineno">  772</span><span class="comment"> *</span></div>
<div class="line"><a id="l00773" name="l00773"></a><span class="lineno">  773</span><span class="comment"> * To make it work, before invoking `T::start_*ops()`, you must supply your execution context/executor -- usually</span></div>
<div class="line"><a id="l00774" name="l00774"></a><span class="lineno">  774</span><span class="comment"> * a boost.asio `Task_engine` (a/k/a `boost::asio::io_contexst`) or strand (`boost::asio::io_context::strand`) --</span></div>
<div class="line"><a id="l00775" name="l00775"></a><span class="lineno">  775</span><span class="comment"> * w/r/t which you plan to `.async_wait()` down the line.  This is done via `T::replace_event_wait_handles()`,</span></div>
<div class="line"><a id="l00776" name="l00776"></a><span class="lineno">  776</span><span class="comment"> * an otherwise optional call.  If using flow.async, this might be (e.g.):</span></div>
<div class="line"><a id="l00777" name="l00777"></a><span class="lineno">  777</span><span class="comment"> *</span></div>
<div class="line"><a id="l00778" name="l00778"></a><span class="lineno">  778</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00779" name="l00779"></a><span class="lineno">  779</span><span class="comment"> *   flow::async::Single_thread_task_loop m_your_single_threaded_event_loop;</span></div>
<div class="line"><a id="l00780" name="l00780"></a><span class="lineno">  780</span><span class="comment"> *   ipc::transport::Native_socket_stream m_sock_stream;</span></div>
<div class="line"><a id="l00781" name="l00781"></a><span class="lineno">  781</span><span class="comment"> *   // ...</span></div>
<div class="line"><a id="l00782" name="l00782"></a><span class="lineno">  782</span><span class="comment"> *   m_sock_stream.replace_event_wait_handles([this]() -&gt; auto</span></div>
<div class="line"><a id="l00783" name="l00783"></a><span class="lineno">  783</span><span class="comment"> *   {</span></div>
<div class="line"><a id="l00784" name="l00784"></a><span class="lineno">  784</span><span class="comment"> *     return ipc::util::async_io::Asio_waitable_native_handle</span></div>
<div class="line"><a id="l00785" name="l00785"></a><span class="lineno">  785</span><span class="comment"> *              (*(m_your_single_threaded_event_loop.task_engine()));</span></div>
<div class="line"><a id="l00786" name="l00786"></a><span class="lineno">  786</span><span class="comment"> *   });</span></div>
<div class="line"><a id="l00787" name="l00787"></a><span class="lineno">  787</span><span class="comment"> *   m_sock_stream.start_send_blob_ops(F); // F is your Event_wait_func.</span></div>
<div class="line"><a id="l00788" name="l00788"></a><span class="lineno">  788</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00789" name="l00789"></a><span class="lineno">  789</span><span class="comment"> *</span></div>
<div class="line"><a id="l00790" name="l00790"></a><span class="lineno">  790</span><span class="comment"> * @note As explained in &quot;Integrating with reactor-pattern...&quot; above, `hndl` is</span></div>
<div class="line"><a id="l00791" name="l00791"></a><span class="lineno">  791</span><span class="comment"> *       a boost.asio I/O object, as opposed to just a Native_handle or even Native_handle::handle_t,</span></div>
<div class="line"><a id="l00792" name="l00792"></a><span class="lineno">  792</span><span class="comment"> *       specifically for the boost.asio integration use case.  If *not* integrating with boost.asio,</span></div>
<div class="line"><a id="l00793" name="l00793"></a><span class="lineno">  793</span><span class="comment"> *       `start_*ops()` is to be used without preceding it by `replace_event_wait_handles()`,</span></div>
<div class="line"><a id="l00794" name="l00794"></a><span class="lineno">  794</span><span class="comment"> *       and `hndl-&gt;native_handle()` is the only meaningful part of `*hndl`, with `.async_wait()` being meaningless</span></div>
<div class="line"><a id="l00795" name="l00795"></a><span class="lineno">  795</span><span class="comment"> *       and unused.  Conversely, if integrating with boost.asio, `hndl-&gt;native_handle()` itself should not be</span></div>
<div class="line"><a id="l00796" name="l00796"></a><span class="lineno">  796</span><span class="comment"> *       required in your code, while `.async_wait()` is the only meaningful aspect of `*hndl`.</span></div>
<div class="line"><a id="l00797" name="l00797"></a><span class="lineno">  797</span><span class="comment"> */</span></div>
<div class="line"><a id="l00798" name="l00798"></a><span class="lineno"><a class="line" href="namespaceipc_1_1util_1_1sync__io.html#aa0b9a3cc6bdc7dedbef4f9e06851aa24">  798</a></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc_1_1util_1_1sync__io.html#aa0b9a3cc6bdc7dedbef4f9e06851aa24">Event_wait_func</a> = <a class="code hl_typedef" href="namespaceipc.html#aa455c7f045059736578ca275fc1a851f">Function</a>&lt;void (<a class="code hl_class" href="classipc_1_1util_1_1sync__io_1_1Asio__waitable__native__handle.html">Asio_waitable_native_handle</a>* hndl_of_interest,</div>
<div class="line"><a id="l00799" name="l00799"></a><span class="lineno">  799</span>                                       <span class="keywordtype">bool</span> ev_of_interest_snd_else_rcv,</div>
<div class="line"><a id="l00800" name="l00800"></a><span class="lineno">  800</span>                                       <a class="code hl_typedef" href="namespaceipc_1_1util_1_1sync__io.html#ac6973c71fc70c6d867b0f2255c642532">Task_ptr</a>&amp;&amp; on_active_ev_func)&gt;;</div>
<div class="line"><a id="l00801" name="l00801"></a><span class="lineno">  801</span> </div>
<div class="line"><a id="l00802" name="l00802"></a><span class="lineno">  802</span>} <span class="comment">// namespace ipc::util::sync_io</span></div>
<div class="ttc" id="aclassipc_1_1util_1_1sync__io_1_1Asio__waitable__native__handle_html"><div class="ttname"><a href="classipc_1_1util_1_1sync__io_1_1Asio__waitable__native__handle.html">ipc::util::sync_io::Asio_waitable_native_handle</a></div><div class="ttdoc">Useful if using the sync_io pattern within a user event loop built on boost.asio (optionally with flo...</div><div class="ttdef"><b>Definition:</b> <a href="asio__waitable__native__hndl_8hpp_source.html#l00080">asio_waitable_native_hndl.hpp:81</a></div></div>
<div class="ttc" id="anamespaceipc_1_1util_1_1sync__io_html"><div class="ttname"><a href="namespaceipc_1_1util_1_1sync__io.html">ipc::util::sync_io</a></div><div class="ttdoc">Contains common code, as well as important explanatory documentation in the following text,...</div><div class="ttdef"><b>Definition:</b> <a href="detail_2util__fwd_8hpp_source.html#l00208">util_fwd.hpp:209</a></div></div>
<div class="ttc" id="anamespaceipc_1_1util_1_1sync__io_html_aa0b9a3cc6bdc7dedbef4f9e06851aa24"><div class="ttname"><a href="namespaceipc_1_1util_1_1sync__io.html#aa0b9a3cc6bdc7dedbef4f9e06851aa24">ipc::util::sync_io::Event_wait_func</a></div><div class="ttdeci">Function&lt; void(Asio_waitable_native_handle *hndl_of_interest, bool ev_of_interest_snd_else_rcv, Task_ptr &amp;&amp;on_active_ev_func)&gt; Event_wait_func</div><div class="ttdoc">In sync_io pattern, concrete type storing user-supplied function invoked by pattern-implementing ipc:...</div><div class="ttdef"><b>Definition:</b> <a href="sync__io__fwd_8hpp_source.html#l00798">sync_io_fwd.hpp:800</a></div></div>
<div class="ttc" id="anamespaceipc_1_1util_1_1sync__io_html_ac6973c71fc70c6d867b0f2255c642532"><div class="ttname"><a href="namespaceipc_1_1util_1_1sync__io.html#ac6973c71fc70c6d867b0f2255c642532">ipc::util::sync_io::Task_ptr</a></div><div class="ttdeci">boost::shared_ptr&lt; Task &gt; Task_ptr</div><div class="ttdoc">Short-hand for ref-counted pointer to a Function&lt;&gt; that takes no arguments and returns nothing; in pa...</div><div class="ttdef"><b>Definition:</b> <a href="sync__io__fwd_8hpp_source.html#l00585">sync_io_fwd.hpp:585</a></div></div>
<div class="ttc" id="anamespaceipc_html_aa455c7f045059736578ca275fc1a851f"><div class="ttname"><a href="namespaceipc.html#aa455c7f045059736578ca275fc1a851f">ipc::Function</a></div><div class="ttdeci">flow::Function&lt; Signature &gt; Function</div><div class="ttdoc">Short-hand for polymorphic functor holder which is very common. This is essentially std::function.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00302">common.hpp:302</a></div></div>
<div class="ttc" id="autil__fwd_8hpp_html"><div class="ttname"><a href="util__fwd_8hpp.html">util_fwd.hpp</a></div></div>
</div><!-- fragment --></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Thu May 2 2024 23:56:38 for Flow-IPC by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
